[vdnkh]

Yes, the author is correct. There is a distinct lack of OSS in .NET. I've been trying to find a project to contribute to among the graveyard on Github. However, I think the author falls flat explaining the why. I have a few thory on this. For so long C# has been a walled garden of closed source software. This closed source software, for the most part, works damn well. Why reinvent a square wheel when there is a shop of perfectly good OEM ones? At work, I'm focused on Getting Stuff Done and the .NET library is great for that.

[bunderbunder]

I think there's definitely something to this.

Another that I think makes a big difference is that Microsoft has historically charged money for reasonably featureful versions of their dev tools. I think it leads a lot of people who work in .NET during the day to do hobby work on some other platform. The freely available dev tools for Ruby might not be any more featureful than Visual Studio Express, but the simple fact that you're working on a different platform from the one where you get to work with all these high-end power tools during the day means you notice that difference less.

Hopefully the new Community Edition will change that that situation.

[tacos]

The tools and libraries from Microsoft are so solid that frankly you don't need an entire class of open source projects.

I don't need to "contribute" and "socialize" with some Python craziness named after a dolphin (though I did!) because Amazon provides a real .NET SDK for talking to AWS. I don't need to wrestle with three different constantly-patched Ruby image libraries because .NET has been able to load and save six kinds of bitmaps via everything from C# to F# to Excel macros since the 90s.

The community around node.js in many ways is an attempt to re-write .NET from the ground up. And they're doing an amazing job. But so am I, when I can write three lines of code in a version of F# that shipped six years ago and issue SQL-like data gathering queries over everything from Wikipedia to the Department of Labor.

That said -- Microsoft's idiotic forges and weirdo repositories were total incompetent nonsense. And the stupidity with their C compilers -- from strategy to implementation -- presented a brick wall to anything resembling clean cross-platform development, which DAMMIT, is a must.

There is a lot more open-source .NET code out there than you'd think. But it tends to be very narrow and very vertical (and often, very high quality) because the core libraries are so broad and so great.

[verinus]

funny thing is I don't think that the tools or libs are still far from perfect:

- WPF tooling is severely lacking in regard to databindings. - libs such as collection classes were far from java standards when release- there is even a pretty good OSS alternative: C5 - there is no standard for filepaths in .Net but even there a good OSS alternative exists: NDepend Path

but I see a lot of improvement in the last years: Rx, ReactiveUI, NuGet, FAKE and much more high quality OSS is beeing created.

[mistermann]

> when I can write three lines of code in a version of F# that shipped six years ago and issue SQL-like data gathering queries over everything from Wikipedia to the Department of Labor.

What's the name this technology goes by, and is it possible in C# (regardless of if it's extra lines of code)?

[tacos]

F# type providers. Quick entry point: http://tomasp.net/blog/fsharp-data.aspx/

It's kinda awesome.

C# provides similar (but somehow less fun) stuff via LINQ providers. Search "LINQ to [noun]" and you'll find plenty of open source code.

[fr0styMatt2]

Why oh why oh why did I have to think about Visual SourceSafe ever again? :P

[WorldWideWayne]

You're not wrong. People who don't work in "enterprise" or even in small/medium business IT shops will never know it though.

However, I think the downvotes are probably a reaction to the hint of attitude which suggests that you're not overzealous about OSS.

[eropple]

I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows to a polyglot microservice architecture on Linux. Surely it isn't the severe drag of dealing with C# and the incredible mess of .NET deployment in a rapidly iterating environment (and, to be fair, this is also in part Windows's fault, there's no good disposable-server model for Windows in a cloud environment because the provisioning stuff is not great, so you make bad decisions like persistent servers and Octopus).

As it happens, I like C#, as a mostly-portable language for writing video games because the runtime has been ported almost anywhere I care about. I have a lot of open-source C# stuff in my Github and have been doing open-source C# since about 2007. But as an ecosystem for high-velocity, agile work, it's got problems. Maybe CoreCLR on Linux, once the bugs are well and truly killed, will be an answer, but it's not there yet.

[tacos]

"polyglot microservice architectures" eh?

Hey Bill! We've got 20 years of legacy code that handles everything from Arrivals Boards to seat assignments in 1627 different aircraft configurations. We got a room full of .NET devs downstairs.

How about we re-write everything in multiple languages! Remember that time we went down for two days because we muffed up our NET 2.0 to 4.0 migration? Imagine how much fun we'll have when we're doing it with Python, Ruby, Rust, Swift, Javascript and Go!

We'll break out the seat assignments in Go. Do the signboards in Python. Web app for refunds in Ruby. I don't know what Rust is but one of the guys downstairs has a book on it with a woodcut of a beaver on the front. Think of all the time we'll save!

Plus our consultant says it's so much easier to spin up Linux VMs!

"Bill, it's the same damn button to spin up a Linux server anywhere. Even on Azure. You just check the Penguin instead of the four squares first. And our deploy scripts work just fine. Even our stupidest apps from the 1990s are one binary file and one text file now. And nobody but Tim is allowed to change the text file."

[eropple]

Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it!

- Almost every developer was converted to .NET to work there, because Microsoft's credibility among startup-focused developers is not great outside of a few specific tools like SQL Server. It's a lot easier to get enough hands to get the job done when you let them use Node (which, I'll be honest, I don't even really like, I'd personally rather write C# but I don't write application code here so it doesn't matter) instead of making them write C#.

- The legacy stuff isn't being rewritten. It's going to be ported to Linux, using Microsoft's own CoreCLR. Parts will be broken out into their own services in order to directly scale them and make it easier to provide separation of concerns; whether it gets rewritten or just parted out is an engineering decision, but so far they seem content to part out legacy code instead of rewrite.

- I'm a DevOps guy. I automate. And you can automate a lot more, to go a lot faster, in a Linux environment. Chef's made strides in Windows, and that's honestly and truly cool, but it's only a first step. There's a reason that most devops folks I know have settled on disposable architectures, where a config change means that the machine should be canned: it reduces ambiguity by removing convergence in favor of guaranteed state. This is extremely difficult in Windows because of the amount of drag induced by the tooling. It takes literally-literally twice as long to bake a Windows Vagrant box as it does a Linux one--I've timed it. It takes longer to build a Windows AMI. It takes longer to deploy one, making your auto-scaling groups less responsive.

-This company's load patterns are unpredictable enough and spiky enough that there is an actual, no-bullshit need for scaling on the order of seconds, not 5-10 minutes, and you literally can't do that in AWS with Windows (and I don't think you can with Azure, either); containerization technology (ECS, Mesos, whatever) is making it very practical to meet these sorts of response requirements.

- Languages must be approved; right now it's just Node and Mono (soon to be CoreCLR), but the build environments (both through Chef and, later, through Docker) support multiple languages. To use something else, one will have to make their case. But instead of assuming a certain level of professional rigor, you started frothing and assuming everything would be written in whatever struck somebody's fancy.

Seriously: fanboy harder. It's clearly working.

[tacos]

You said "polyglot on Linux." And then you describe languages as follows:

> - Languages must be approved; right now it's just Node and Mono (soon to be CoreCLR)

I'm not a troll but dude, those aren't languages.

There's also no need to be adversarial here. What you're talking about is a refactor using .NET and hosting on Linux. This is not radical thought and is actually part of the official ordained .NET strategy. It'll work fine.

A need for "5 second container startups" sounds like bullshit to me but this will be solved on all platforms within the next two years. In the interim AWS Lambda and Node.js is an interesting place to play.

None of this has anything to do with the fact that .NET libraries are large and robust and the fact that Microsoft shipped such a huge, working platform had an impact on OSS bootstrap-style development of components, for better and for worse.

[manigandham]

Specific question: What kind of load needs scaling within seconds? If it's so sensitive why not have extra capacity available?

[WorldWideWayne]

Sounds like you work at a startup, not an "enterprise-by-any-reasonable-standard place".

Lying to shape your argument doesn't really fly around here.

EDIT: Furthermore, looking at your sites pretty much proves that you're a liar. You don't work at some enterprise shop that just decided to go open source, you're a consultant that pushes open source.

[WorldWideWayne]

Good luck with that! I hope it goes better for you than it did for the city of Munich.

[eropple]

So, okay, dude, let's have some real talk: you're generally a low-information troll here on HN--not bad enough to flag, bad enough to notice when your name comes up because it's almost never constructive or useful. But literally even you, as wrapped up in the weird little agendas you consistently show through your posting history, should know that attempting to use a desktop transition program (which, as it happens, I said nothing about) to slag on a migration of server software to another environment--and with CoreCLR, a very similar one by the same people--is weak sauce.

HN doesn't need shitposters. Do better, yeah?

[WorldWideWayne]

That's your real talk?

At least you could have been a tad more original or at least entertaining if you're going to resort to insults.

[bsder]

> There is a distinct lack of OSS in .NET. I've been trying to find a project to contribute to among the graveyard on Github. However, I think the author falls flat explaining the why.

Simple, Microsoft killed it with the transition to .NET.

People have forgotten just how extensive both the open and paid ecosystems were around Visual Basic 6 circa 1999-2001. Those ecosystems were huge--they absolutely dwarfed open source ecosystems in the same timeframe.

Then Microsoft completely stomped it flat with .NET in 2001.

After that, people with two brain cells to rub together figured out the decision matrix really quickly.

1) Stay with VB6 until it finally breaks (still running today)

2) Switch to something non-Microsoft like Java

3) Switch to web-based stuff (Hey this XMLHttpRequest stuff is kind of cool)

4) Port it to Visual C/C++--whoops--the Microsoft C compiler sucks donkey balls

5) Port the code to Microsoft's new crap until they stab me again

And then they wonder why, 15 years after shooting their developer ecosystem in the head, their ecosystem is inferior.

[jevgeni]

The switch from older (VB6, etc) model to .NET could be compared to the switch from Python 2 to 3, only MS didn't wuss out and actually made the braking change instead of dragging everything out. You can call it "stabbing". I'd call it "necessary progress".

Just because an ecosystem is large doesn't mean it's good. I once tried to switch the automation in our team from batch files to Ruby. Huge mistake. Try finding any Ruby gem that: works, has the functionality you need, is well documented, and doesn't rely on Rails (honestly, I don't want to load a whole web framework to figure out a recurring schedule). Went with Powershell in the end and never looked back.

[bsder]

> The switch from older (VB6, etc) model to .NET could be compared to the switch from Python 2 to 3, only MS didn't wuss out and actually made the braking change instead of dragging everything out. You can call it "stabbing". I'd call it "necessary progress".

To what end?

There were billions of lines of VB6 code that got orphaned (possibly trillions). Lots of businesses simply stopped at WinXP/VB6 for this reason--I suspect this is more responsible for the continued existence of XP than anything else (hardware drivers are probably the other).

So, we now have obsolete code along with security nightmares frozen in amber and in return Microsoft killed their developer ecosystem and lost a bunch of revenue because people simply stopped in place or moved to non-Microsoft ecosystems.

Who benefited? I'm sure some manager got great numbers for a a year or two while some fraction of the developers had to upgrade. Of course, nobody measured how many developers were lost in that transition.

[digler999]

> the author falls flat explaining the why.

Probably because the proprietary ecosystems are built from the ground up to support the profiteering enterprise that is/was microsoft. They don't make money by embracing open standards. They make money (or at least historically) by creating technical monopolies with short shelf-lives that naturally support vendor lock-in. They make money by creating the problem (obsolesence ) and selling you the solution (*Yipee! version (N+1) Super Enterprise is officially released. Time to upgrade, everybody !).

[maxlybbert]

But Java had a lot of open source projects around it before Sun released the source code.

[jasode]

Whether/when Sun released the source code isn't as relevant as the fact that JDK and JRE 1.0 in 1995 were free.

Microsoft .NET 1.0 development in 2002 required paid tools and a free version (Visual Studio Express) didn't happen until 2005. VS Express was also crippled in comparison to the paid product (VS Professional).

We can't just look at the technical features and syntax of C# and compare to Java. (E.g. they both have GC, they both have virtual machine intermediate language, etc, etc.) You also have to compare the social factors that built up around each.

MS .NET/C# was a continuation of Visual Basic 6.0, Access db, and FoxPro. Those dev tools were used for line-of-business enterprisey apps. Even Microsoft's initial offerings for web dev was ASP WebForms which tried to continue the VB WinForms desktop paradigm into a HTTP/HTML world. That was the social situation around MS dev tools and NET 1.0 continued that. It continues to this day.

Java had a different set of social dynamics -- and that also continues to this day -- even though a significant chunk of Java dev is also line-of-business CRUD enterprise apps. If anyone was a hacker or student with no money outside the domain of boring corporate CRUD apps, it was much more likely that he/she would scratch an itch with Java instead of C# (if it was down to a choice between those 2).

It is not an accident that new things like Hadoop, Elasticsearch, iText for PDF, etc got written with Java first. Even though there's no technical reason to prevent those projects from getting birthed on C# before Java, the inertia of C#'s community dynamic keeps it from happening. The past matters and it overwhelms any technical equivalence between the platforms.

[jameshart]

In general, you're correct about the difference being social, nt one of licencing. You're wrong on one thing: Microsoft's .NET 1.0 CLR and compilers were also free from day one. You never HAD to use VS to develop with .NET, any more than you HAD to use NetBeans or Eclipse to develop with Java.

[jasode]

Yes, the .NET SDK had a command line compiler so theoretically, it could compile .cs files for free. However, nobody used it for serious Windows Forms GUI type of work. Realistically, corporations and hobbyists had to buy VS Studio to write non-trivial apps. On the other hand, people were writing Java GUI apps with free tools. Eclipse was free back in 2001 before .NET 1.0 was released.

The only common use case I remember for the free C# command line compiler was to type in exercises from C# tutorials.

Also, even if compiling C# source code was free, the execution stack for the NET runtime was not free. MS Windows operating system licenses and MS SQL Server cost money. In comparison, Linux and MySQL were free. The different costs for deployment affected social dynamics as well.

[bunderbunder]

True, but I shudder at the thought of having to manage msbuild files by hand without the help of Visual Studio.

[jameshart]

For .NET 1.0, there was no msbuild - csproj files were not build files, and they weren't part of .NET, but part of VS. And until James Duncan Davidson got fed up with maintaining batch files and threw together Ant to manage his Tomcat build process, there was no build solution for Java, either.

[recursive]

meh. It's not that bad.

[MichaelGG]

Free on Windows. And only supported on Windows, despite Rotor. That's a fairly non-trivial "hidden" cost.

[ghuntley]

https://github.com/dotnet/coreclr

Windows, OSX, Linux, FreeBSD

[MichaelGG]

Comment was in respect to .Net 1.0. They had a BSD version well before this,too, but just for "research".

[cmdkeen]

The significant word there is student. CS departments started using Java for an awful lot of teaching. I would wager that plenty of those "hard" OSS projects have a genesis in academia, and even if not that Java became a sort of lingua franca for writing code you wanted discussed or accepted in that sort of way.

[fla]

I think it's important to note that Microsoft wasn't the platform of choice to act as a server - for most of the projects at least. Also, big corps who developed server-side OSS kept it for themselves.

[fla]

s/server-side OSS/server-side software