Really the simple issue has always been the same with MS-platform based OSS; People look to MS to provide the canonical frameworks, tools, and libraries. MS is far more used in corporate environments as a portion of their market, and are more subject to business decision making; much of that focused on RAD / designer tooling.
There's a different philosophy in the open source world - python, perl, c - none really have 'de facto' answers to persistence, logging, services, etc so There's a plethora of approaches and libraries for any needs. MS provides EF, so you have to defend any alternate solution to business; it's perceived as risky. Even using tools not of MS origin, despite no close surrogate from the 'official' tools (ala Redis, 3rd party libs) is something you have to find approval for. MS tooling is automatically excluded from this. This isn't great for MS either, because they now have to produce these 'ideal' libraries, and the strength of their platform is now judged by library implementations.
I'm really not sure what the solution to this problem is unless they really get to sponsoring projects with effort, money, and tooling. They have programs in place for this, and I can see there's a lot of outreach going on for this reason.
I think there is a shift happening slowly that simply needs to progress and happen fully. With more developer stuff coming from Microsoft embracing open-source, people just need to realize that Microsoft is a part of a larger .NET ecosystem space. Not the other way round.
I've worked on open+closed source in enterprise startups with people that come from both MSFT- and Linux-centric worlds respectively. The MSFT centric-people tend (not all) poo-poo open source as a complete waste of time and/or lack of business savviness (helps competitors too much). There is some open source contributions in such shops, but usually only if it helps (and doesn't seem to hurt) the bottom-line.
PS: Unfortunately, most Fortune 2000 enterprise (ms and non-ms shops) abuse the fuck out of open source and give zero back (time, $ or help). I really think there should be some "community charge" funding model which doesn't make it nakedly for-profit but rewards people that contribute, maintain and support useful code that is widely deployed so they're not completely abused as unpaid crowdslaves.
I understand your feelings but legally speaking the only abuse of that kind would be taking GPLed software, modifying it, distributing it and not sharing it back. If the software has been licensed with BSD or similar licenses that don't require to share modifications, then the original developers are perfectly fine with not seeing anything coming out from those corporations. Their choice, no abuses.
Absolutely. It is in their own interest to share contributions upstream. If they don't, they are forced to re-apply their patches over-and-over or just not upgrade.
If MSFT centric people think open source is a waste of time that helps their competitors, and open source contributors are wasting their time helping their competitors, then doesn't that mean the MSFT centric people are perfectly right, and people really should avoid contributing to open source unless it help their own interests directly?
If you want open source and user pays at the same time, then it's not really open source. What you end up with is closed source which has already worked well for a lot of companies.
I think it is important to realize that the .NET OSS ecosystem is not something that has been around for a long time. In the F# community, it truly started working as an "OSS ecosystem" only a couple of years ago - and the rest of .NET is following - and I'd say it is only starting to really exist now. Although .NET has been around for ages, people are only learning what OSS means and I think the F# community is leading the way here.
There are definitely interesting hard problems that are being solved in the F# community. For some larger and fully open source projects that exist out there check out:
* http://www.m-brace.net - A fantastic library for doing interactive cloud computation that takes a slightly different approach than Spark (think "cloud monad" :-))
* http://fslab.org - A nicely integrated collection of data science libraries with fantastic data access features and R integration (supported by OSS community and a finance company)
* http://websharper.com - An open source library for doing web programming that has a pretty unique integration of client-side programming (translated to JS) with server-side programming
* Also, I would like to mention FAKE, Paket and ProjectScaffold (http://fsprojects.github.io/ProjectScaffold) which enable the community build OSS libraries with smooth build process and great documentation.
Is it impressive compared with longer and more established OSS communities? Maybe not. But those are all things that happened over the last 2 years. It's enough to make me feel that the F# and .NET ecosystems are heading in a good direction.
The (now abandoned) Spring.NET project[1] was started in 2004, not too long after (Java) Spring started.
It's easy to criticize Java Spring, but it's a good example of a long-lived successful Open Source project. It's also easy to argue that Spring isn't as useful in .NET as in Java.
But I can pull up many, may other examples (the .NET Lucene port etc).
My point is that the .NET OSS ecosystem is NOT a new thing, but it keeps getting killed off. The typical example is that a .NET project starts to solve a problem, gets it 30-40% solved, then Microsoft releases a project that solves a different 30-40% but sucks all the oxygen out of the ecosystem.
While I agree with you that Microsoft was getting in the way of the ecosystem, I believe that since last year this is no longer the case.
I tried, and couldn't find exact date when Microsoft officially endorsed Newtonsoft.Json as THE way to handle json in .net. But I believe that this happened just last year. Look, in 2011 Scott Hanselman blogged about this library [1] and the comments (esp. the first one) are pretty interesting. Here, .NET tried to solve a problem and community did a better job, and just recently Microsoft recognized it.
It's been abandoned? (serious question) That really is too bad. It was a solid project used on several .NET projects in which I participated "back in the day."
BTW, I completely agree with your summary point. There appears to be a cultural rejection of .NET OSS projects.
It slowly fell behind. I made the mistake of using it for a product pre-MVC. When MVC came along they jumped the shark and we ended up ripping it out and replacing bits with Autofac and some light weight abstractions we put together ourselves.
Indeed. And it's very possible that the .NET OSS ecosystem will grow dramatically soon, once its core components, compilers, and build tools finish being open sourced and become stable on non-Windows platforms.
The article accused people using .NET of not choosing to work on hard problems. I suspect that's it's the other way around. People working on hard problems have chosen other tools that they felt were more appropriate or effective at the time.
For example, if people doing hard things felt that a Linux hosting environment was most suitable for their solving hard problem, that basically ruled out .NET. Once .NET applications can be safely, reliably run on Linux, the case for using .NET becomes much stronger.
I've rolled this around a bit and have come down on the side that there are two factors at work.
1. Just plain Microsoft Hate. Couple of times someones asked me about what language to use for some GUI that messes with a database and does some other thing, running on Windows and 'maybe Linux' I tell them that C#/.net was made for that kind of thing. And they recoil in horror as if they just realized that I'm Satan. Then they go off and mess around with QT/C++ for a week before giving up.
2. C# has good inter-op with C/C++ libraries. So if there is an open source widget in C/C++ you need you can usually just build it as a dll with some wrapper magic and reference those in your project.
I think the status of the development tools has/had a lot to do with it. As a .NET developer, it's always been unclear until a few years ago as to how you could get the free tools and what you could do with them.
I'm specifically talking about Visual Studio here.
So there was always this perceived barrier to entry, even if it wasn't true -- for example with C++ I know I can just grab a linux box and have gcc and use it. With .NET, until recently it was -- pay for Visual Studio? Use the free version but it's only an express version so can I use it commercially? Use MonoDevelop which is alright but doesn't feel quite as nice under Windows?
Now that we have an official toolset on Linux and the licensing behind Visual Studio seems a hell of a lot less confusing, I think we'll see the community grow.
There is also the hate thing; but I'd counter that with the observation that there's also a lot of Java-hate out there too. They aren't seen as "hacker's languages" but "ewww yuck big bank enterprise-y languages". So I don't know.
> They aren't seen as "hacker's languages" but "ewww yuck big bank enterprise-y languages".
They're seen as "Languages this evil SOB of a company owns and who knows if it could decide to patent something and enforce it against me".
As in, patent law is complex. Guarantees sound more like marketing of the used-car-dealer and sawdust-transmission variety than actual known-good documents like the GPL, which is, after all, founded on copyright law. Copyright law seems simpler: You own specific files, not abstract hand-wavey ideas. You can't use copyright law to go after someone for the unforgivable sin of coming up with the same idea a bit after, or a bit before, you did.
(Edited to add: Before you accuse me of FUD, tell me how I could know I'm not spreading FUD without becoming an IP law expert first.)
So:
.Net is Microsoft's ecosystem.
Java is Oracle's ecosystem.
Which company is less likely to find a loophole in whatever guarantee they've pledged and use it to squash me like a gnat?
I'd agree with this too; at least to an extent -- especially given Oracle's recent actions wrt. to Android/Java.
Now that you mention Intellectual Property, I wonder.... Does the fact that .NET is used in big enterprises and big enterprises tend to have strict employee side-work exclusion clauses or "we own everything you do" clauses also play a part in slowing down the .NET OSS ecosystem?
At my last job we ported the build scripts to FAKE and afterwards many people (everyone?) felt that it had been a mistake. There were probably a few reasons for this:
1. we wanted to split the build scripts across multiple files, as we had multiple builds sharing common parts of a build process, and the only way of doing that with F# seemed to be writing a bunch of scripts that #load-ed each other. This was unpleasant.
2. at the time FAKE tried to kill processes it launched at the end of a build, but this was not implemented terribly well, so if you ran multiple FAKE builds in parallel on the same Windows box there was a fair chance they'd start trying to murder each other, and you'd end up having builds fail for no reason. This was fun to debug. IIRC FAKE was trying to track processes using process ids, but these get recycled...
3. we weren't using F# for anything else in the business, so having the build scripts in F# meant even less people wanted anything to do with them.
Here's a Q&A with myself that I wrote at the time about the #load-ing stuff:
Q1. do you recommend constructing build systems out of many .fsx scripts that #load each other?
A1. no. the #load mechanism of f# scripts is lamentable, in that it does not like you #load-ing something twice, yet no mechanism like #pragma once or #define / #ifndef is provided.
Q2. couldn't you work around that problem by not making your "library" .fsx scripts #load anything, and write a top-level "main" .fsx script that #loads all transitive dependencies exactly once in the correct order?
A2. yes. yet that sounds strangely similar to what you might wish a build system to do for you.
edit: and now I'm reminded of something else, that isn't to do with FAKE, just another fun windows parallel build interaction thing: you run a couple of builds on a windows box using jenkins. in each build, you use msbuild to compile some visual studio project. msbuild launches some mspdbsrv process that is cleverly shared between msbuild processes. then the first jenkins build finishes, and jenkins cleverly kills all processes launched by the build, including mspdbsrv, while the second build is still using it. hurray for interactions between two different pieces of clever software! at least this one is fixable by setting environment variables telling msbuild not to do this once you figure out what is going on.
Maybe this is why I'm loving F# more and more as I continue to dive in. I write C# at my day job, but there really is more interesting OSS development going on in F#. The community seems very approachable and I find myself actually wanting to contribute.
What I'm seeing in all these comments is that there should be a better OSS ecosystem in the .NET community.
I think the problem here is that we're trying to compare the Java OSS ecosystem with the .NET Framework community. Essentially .NET isn't the language here.
I think that the main problem is that developers stick to what's given in the .NET framework, instead of building awesome things outside that.
Probably it's heading toward where niche ecosystem/platform is today: Haskell, Erlang. But with less uptake because the similar audiences/users of those platforms are less likely to touch Microsoft... (even if they're reaching cross-platforms)
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.
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.
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.
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.
> 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)?
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.
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."
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.
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.
I also wondered that. I think a lot of technical people are irresistibly drawn to solving scale & performance problems by resorting to ever more complex rube goldberg machines & processes rather than just throw a few measly grand of hardware at it and be done.
Stackoverflow is one example of scale with a pretty boring architecture.
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.
The remarkable thing is that I don't need to push anything (well, okay, I pushed Chef over Ansible, because for nontrivial setups you end up needing some sort of unified orchestration layer and at that point you might as well use the more mature Chef than Ansible Tower). The still-Windows shops I talk to are pretty unified in their desire to branch out into other languages and environments. That one in particular was sold and already well underway before they brought me on-board to help them through it. But, y'know. Whatever you want to believe, chief. :)
> I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows...
This was in response to someone who said that Microsoft non-open .NET framework and Windows works really well for most enterprise shops.
Then you come along with your anecdote that "the 'enterprise' place I'm currently consulting at is moving away from Windows" as if that were some sort of trend that you just happened to be involved in.
I bet it's not even a typical enterprise. Tell the truth - it's a game company, right? Or something else that is equally non-enterprisey...
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.
> 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.
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.
> 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.
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 !).
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.
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.
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.
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.
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.
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.
Right because yes there could be a ton more open source solutions out there. Also right because most of them are either shit, commercial or abandonware. This is a big problem. We imported a lot of stuff and found it was mostly crap (Nservicebus, justsaying come to mind)
Also wrong because a massive portion of what we do is a solved problem on .net. There's not a whole load of stuff to reinvent.
What I'd like to point out though is name me one platform I can build stuff for desktop, mobile, web, embedded, plugged into office applications, deployed by a single click from the web, deployed to single machines, deployed to thousands of workstations, will talk to just about anything under the sun from REST, SOAP, WS-*, databases, spreadsheets, document models, message queues, serial ports, pipes, TCP channels, has a request broker and distributed object model and has several data access methods from ORM, SQL, table gateway abstraction and has very decent tooling, provisioning, integrated deployment, testing, profiling and backwards compatibility going back 20 years all out of the box with no glue required?
On top of that there's support which is actually very good for everything above.
Nope there's only one and Java doesn't come close.
A good chunk of that is the "invented here syndrome". With EF, WPF, ASP MVC, MEF, etc, plus annual MSBuild conferences, .Net has far more internally-developed ecosystem than Java. Which tends to promote the idea that the MS way is the right way, and if I need something else I must be doing something wrong (or I need to wait till next year).
Perhaps MS should just kill off all these frameworks and force the community to drive them.
That's one of my favorite things about Microsoft. Whenever they release a framework or a product, there's a tendency to just call it whatever the name of the technology is as if they invented the whole thing.
SQL Server - When .NET developers say SQL they mean SQL Server 90% of the time it seems.
MVC - MVC4 is a .NET Rails clone. Named MVC as if Microsoft originated the design pattern that was used to clone another framework.
> When .NET developers say SQL they mean SQL Server 90% of the time it seems
I've never experienced someone saying SQL and meaning SQL Server. In fact it's always been about SQL the language, agnostic of the fact that SQL Server has a SQL engine.
Microsoft SQL Server is named so because it originated from `Sybase SQL Server`. Microsoft joined forces with Sybase to port it to Windows NT. The name is kept after they went on their separate ways.
ASP.NET MVC is named so to clearly differentiate from ASP.NET Web Forms (i.e. primarily for branding). Even now, sometimes when people talk about ASP.NET, they actually mean ASP.NET Web Forms.
They named their framework ASP.Net MVC, as it is an MVC framework for ASP.Net, The naming isn't that problematic.
Lots of people in the close-minded cult of Microsoft (which does not include all Microsoft devs.) both shorten the name to "MVC" (which isn't necessarily bad in certain contexts) and have little-to-no understanding of what MVC is other than ASP.Net MVC, so both themselves confuse the pattern with the Microsoft product and promote others doing the same thing.
Roughly the same thing happens with Microsoft SQL Server (which becomes just "SQL").
Microsoft's changing their approach, but it tends to take a long time for the rest of the .NET ecosystem to catch up.
Case in point: Judging by all the .NET code Microsoft has up on GitHub, they've more-or-less completely switched over to xUnit.NET for their testing framework.
Meanwhile, in most Microsoft shops MStest is still considered the best-in-breed option purely by virtue of the fact that Microsoft wrote it. NUnit is a strong counterculture alternative in the same way that espresso drinks are still considered a counterculture beverage in some circles. And nobody has even heard of xUnit.NET.
They originally tried competing for years by offering their own AppFabric, until finally they conceded to recommend Redis after having ported it on Windows so you can use it on Windows Servers/Azure.
That's certainly a new approach for Microsoft. They have a long history of writing things that are clearly inspired by open source projects, but failing to mention the inspiration:
BITS is nothing like rsync. The purpose of BITS is to allow low-priority downloads/uploads to progress without impacting the real-time network traffic on the machine. (The classic use being to download Windows Updates without annoying the user by slowing down their web surfing.)
Rsync exists to synchronize folders between machines.
Thanks for the correction. I have never used BITS, but at one time I thought the description of "intelligently transfer files over the network" sounded familiar.
To clarify, by "invented here syndrome", I meant for the MS shops / MS consultancies. Rather than building frameworks themselves, they search for off-the-shelf solutions provided by MS or a partner. The managers at those shops think "the MS way is the right way; don't 'invent here'".
It's due to NIH and the "power of defaults" as soon as MS recommends a library, it effectively kills any chance that an alternative OSS will gain enough mind-share/traction to survive on its own, which a lot of the time given the lack of adoption, OSS Authors end up abandoning the project since the effort to further develop, support and maintain them doesn't justify their negligible impact.
NUnit and log4net were originally ported from Java and defined their respective categories in .NET which MS's NIH alternatives aren't able to match (e.g. they don't run on Mono).
MS doesn't offer anything comparable to Moq or AutoMapper which explains their success.
> The .NET platform is like no other; Microsoft has PR channels, Evangelists, MVP Award programs and control over VS.NET that commands a strong influence over .NET mindshare where they're seen as the authoritative voice for the .NET ecosystem to most developers. Historically they've only used their influence to validate their own libraries and frameworks which has contributed to many .NET companies being reluctant to deviate from Microsoft's prescribed technology stacks and explore alternative solutions.
This also explains why the .NET Ecosystem is slow at adopting popular technologies (prevalent in other platforms) where they don't gain traction until MS PR validates them, inc: MVC, Testing, NoSQL, MQ's, etc.
Here is some blatant speculation about the problem with .NET and OSS.
The the larger problem is one of self-selection. C# devs are not alone in not contributing to opens source software. The vast majority of devs don't make meaningful contributions to OSS. It's just the the few people who get really stoked about open source software and love making a positive contribution to world through software have been turned off by Microsoft's behavior for the last 10-15 years. So they never entered the .NET/C# world to begin with.
The second is incentives. Java shops are much more comfortable with open source then .NET shops. Open source is still terrifying to many enterprise customers, and a lot of .NET shops. And the incentives besides making a positive contribution to the world [0] for contributing to OSS are it looks good on your resume, maybe you could consult on it, and getting to be paid to work on your own OSS project. But with most customers not using OSS the developers don't get a lot of personal benefits from it.
The third is how bug fixing your favorite OSS acts like a gateway drugs. In the past .NET devs wouldn't have very much experience with any OSS. If they found a bug in their favorite framework they would report it. End of story. Everything they used was closed source MS stack. But if they were working with Java(and probably working on an OSS library) they could dive into that library and make the fix themselves. Now that all of the core libraries for MS are being open sourced many more devs will start to get familiar with what it's like to be able to make a change to library or framework you use on a daily basis. And hopefully some will catch the OSS bug.
I think this will change. As Microsoft pushes more OSS, enterprise customers will see it as less scary. Devs who are into OSS might start considering .Net as an option. And finally devs will start to get a taste of what it's like to get to fix a bug on a framework or library that 1000's of people use.
[0] -see point 1 why people who wanna make a positive contribution to world through open source software shy away from being .net developers
The 'bad stuff' from an OSS point of view is, generally, longer ago than that.
- "Embrace, Extend, Extinguish": 1995
- US vs. Microsoft Corp: 1998
- Halloween Documents: 1998
Scraping under the 15 year bar:
- Microsoft vs Sun settlements: 2001-2002
- Ballmer "Linux is a Cancer": 2001
SCO vs IBM was 2003, so I guess fits into the '10-15' ballpark, but I think "over the last 10-15 years" makes it seem more continuous than the evidence suggests. If you were to describe Microsoft's behavior over the last 10-15 years with respect to open source software, I think a fair assessment would be "improving".
I'm not, honestly, trying to be an apologist for this stuff - it was, clearly, Microsoft policy for a long time to deliberately and pretty unscrupulously undermine Linux and Java and open source adoption. It doesn't appear to be policy to compete unfairly any more, and in some cases MS is producing technologies which support usage of non-MS-originated open and open source technologies. Can we begin to move on a little?
The OOXML "standardization" is more recent. So is Silverlight.
In the end I'm always puzzled when people talk about Microsoft or Apple as if it was one dude who ran over your cat in the early 2000s.
It's a vast corporation, whose attitude towards opensource has improved, at least in the cloud and .NET environment (though I've read people comparing Microsoft to Red Hat and Joyent, which is clearly way off).
For instance, the issue I find most egregious is selling Windows phones with a restricted bootloader, just like Apple does.
Why? Why should we forget that the entire company (currently) is funded by the crimes of the past?
Are they a person who made mistakes when young and now deserves a second chance?
I'm not anti-capitalistic but I'd never deal with, for example, a consultancy that cheated me in the past even if they had all new consultants and managers - some things just don't change. And even if... they might have turned over a new leaf but do they deserve another try and are you obligated to give it to them? Wouldn't it be better for everyone to offer the opportunity to a potentially honest competitor?
As long as people are willing to forgive companies, companies are prepared to bilk them.
And if people never offer forgiveness, then there's no incentive for them to improve. I guess you're just hoping that if you ignore them they'll go away?
Doesn't explain why Java developed a robust OSS ecosystem long before it went open source. Java did benefit from the model Sun set up on J2EE of setting out JSR 'specifications' and only providing limited capability reference implementations, which made it possible for the Apache Java ecosystem to spring up, initially around the Xerces and Xalan XML libraries. Maybe - maybe - Microsoft is starting to get on board with this kind of model now.
I agree there was a lot of similarity between how open Java & C# were as they evolved. However, Sun's engagement with the open source development community was much, much, much better than Microsoft's. Sun had its problems, but they actually had worked with that community in the past. At the time Microsoft was openly combative.
I mean... It's nice that they're trying to "come clean," now, and all. But it's sort of like a criminal who was never punished now claiming to be legit because he's seen the light... and there's PLENTY of us out there still who still feel wronged by the past.
Companies aren't monolithic entities, MS has tens of thousands of employees. Just because the upper level of the upper level of upper level management (which is a different group of people than engineering) might have been hostile towards it years ago doesn't mean that everyone there agreed with that stance, and it doesn't mean that that management culture has persisted to the present day.
Ultimately the only thing that matters are actions, not the human personality traits that people project onto anthropomorphized corporations. I'm sure there are plenty of people there now that are anti-OSS, and pro-OSS, and everything in between. It doesn't matter. All that matters at the end of the day is what software is released and how that software is licensed.
> Just because the upper level of the upper level of upper level management (which is a different group of people than engineering) might have been hostile towards it years ago doesn't mean that everyone there agreed with that stance, and it doesn't mean that that management culture has persisted to the present day.
Fallacy of composition?
> Ultimately the only thing that matters are actions
Which were terrible. MAYBE they are better NOW. :P
> not the human personality traits that people project onto anthropomorphized corporations
So corporations are run by computers, I take it?
> anti-OSS
This position is literally irrational UNLESS you are a profit-making entity that considers OSS a threat to your own for-profit business model.
Not so much where the profit comes from selling software.
If Microsoft open sourced Windows and Office they would instantly stop making money, hence they will always have an uncomfortable relationship with open source.
> If Microsoft open sourced Windows and Office they would instantly stop making money
If Microsoft open-sourced Windows and Office and offered enterprise technical support contracts at the same price they offered enterprise licensing contracts for the same level of support that was included in those contracts, they'd probably keep making money, though perhaps somewhat less (they'd probably decrease costs, though, as well, since both the administrative side of license management and building license enforcement mechanisms into all your software has a cost.)
> If Microsoft open sourced Windows and Office they would instantly stop making money
It's funny because I don't actually think this is the case. Not completely, anyway. That's their fear, but I think that the upside in the end would counteract the immediate downside.
It could also be structured interestingly- Basic Windows could be free, but certain diffs/patches/drivers could be for-pay (such as higher-performant stuff, graphics stuff etc.) A mix of free OS and proprietary profitable stuff. They could also employ an army of Windows consultants...
The fact that until recently .Net only run correctly on windows where the licensing is more expansive than linux, and that all the big player use linux to develop their cloud capacities; it means that the ones who seek to develop at scale didn't bother with .net. Now that .net is open source, MS has still at lot of work to fix all the issues on linux, but maybe the ship has sailed and developer won't bother to port on .net all the hard work done for java as they are really similar.
There is always new stuff and C# is going to still be much faster than say a python or ruby so just like go replaces a lot of stuff written in those languages it wouldn't be crazy to see C# used as well.
The ship hasn't sailed, but when they get to the ship it better be good enough.
OP is suggesting that C# is competing with languages people are picking to replace Ruby or Python. A recent example is Parse[1] moving to Go. C# and .NET was their second choice.
The level intellectual laziness is immense. Most of the developers, me included look at Microsoft for guidance than embracing hard problems and solving it for ourselves. This does not mean .net is filled with incompetent programmers but it is full of "unless you pay" programmers.
Do you really believe that it'll ever be on the JVM? Why would Microsoft put any effort into that? CLR is now cross platform. If you want functional programming that is similar in style to F# (and ML-family of languages), check out Scala.
It's got some severe built-in limitations. Firstly and most importantly, there is no support whatsoever for the proper tail calls (and F# is using the .tail prefix quite a lot).
Secondly, no stack allocation (value types in .NET).
Another thing which may harm optimisation significantly (although not sure if F# is using it - but the other functional languages most definitely would have benefited from this) is a very low hard limit on a method size, which forbids any extensive inlining and specialisation.
Thanks for clarifying. I think tail call conversion to iteration for Java bytecode could be added to a JVM implementation without changing the spec, and you could also do it when converting F# to bytecode. Apparently it's on the todo list but not high priority.
Stack allocation is trickier if it's specified in F# code, because it isn't part of the VM spec, but automatic stack allocation for Java has been demonstrated in a research context and I think either HotSpot or J9 can do it too.
The method size limit is something like 2^16 bytecodes, but even if that's a problem, JITs are free to inline beyond that as much as they want.
So, I agree it would take some work but I don't think it's fundamentally impractical. Adding stack allocation to the class file format would be the hardest thing to push through I think.
You cannot convert a tail call to an iteration in a generic case.
Consider the following:
`let f g x = g x`
Here, call `g x` is a tail call, and you've no idea what `g` is, so you cannot statically inline it or convert to a loop.
> JITs are free to inline beyond that as much as they want
JITs are primitive and do not have much time to do anything interesting. Inlining is very important alongside with partial evaluation - which is very heavyweight and must be done statically.
Anyway, without proper tail calls inlining on JIT level won't help much.
> it's fundamentally impractical
Everyone who ever tried implementing any ML-like language on top of JVM failed miserably.
Haskell is nowhere near an ML-like language, it's lazy, while ML is eager. And Frege is nice and all that, but it's very far from being efficient, nothing close to F# performance.
I don't think you can say "Haskell is nowhere near an ML-like language" based on just lazy vs eager evaluation.
See here[0]:
> Since Haskell is inevitably an ML (descending from Lazy ML) derivative, one might begin by pointing out the similarities:
- First-class support for algebraic datatypes (disjoint unions)
- Pattern matching on primitive and custom values
- Arbitrarily higher order functions
- Type synonyms
- Hindley-Milner Type Inference
- Parametric Polymorphism (define arbitrary Functors etc.)
- Ad-hoc polymorphism (Haskell through type classes, SML through modules)
- scorn of inclusion polymorphism (sub-type relations, a la object-wise inheritance)
- Monads (and other exotic algebraic structures)—"Haskell has monads" is a common claim of superiority, but the reality is that at the language level a monad is nothing more than an abstraction pattern, and hence every language (can) have monads. Including a monad or not in any given language is a library-level decision.
> While the bread-and-butter language features may be similar, building software in Haskell vs SML is actually quite a different affair:
It's not "just", it's fundamental. We're talking about an efficient implementation, remember? And therefore the underlying execution semantics is the single most important thing for classifying languages. The rest that you listed is very high level, consider it syntax sugar. It is all lowered down long before any of the important optimisations start to kick in.
> So we can see a lot in common there.
Not that much. Just think of the deeply fundamental difference between SECD and, say, STG.
In addition to the various theories abounding here, I've got another one: Microsoft has historically never been big in distributed systems specifically.
The licenses for their operating systems have always acted to make farms of Windows machines rare. Until fairly recently, the administration approach made it painful. Microsoft had good support for client-server systems, but you did it their way, which wasn't "reactive".
Here's a quick question: Anyone know of any networking/distributed system developments that came out of a Microsoft environment?
Do something mind-blowing instead – use Storm to make a real-time recommendation app for solving the paradox of choice whenever I walk into a 7-11 and try to figure out what to eat.
I'm reaching for a word that means "an example which is almost exactly the opposite of the concept it's used to illustrate" -- incongruous?
I'd much rather someone write a one-sentence description of what the library does in plain English, so I (and everybody else reading the article) could get the "learning" without the "going".
Since you didn't tell me what it does, I'll assume you have no idea either. ;)
I regularly ask questions before seeking knowledge on my own, just to check back on my post a few hours/days/weeks later.
The point of asking the question is to leverage others experience to guide your learning, and provide a reference for those in the future that have a similar question.
The post has no question marks, nor does it seek knowledge. Instead, it makes declarative statements implying that the knowledge is actually probably useless.
Re: the Akka.Net stuff, there is indeed an implementation of an Actor model framework - Orleans. Now it was developed in house at Microsoft and hasn't gotten a lot of attention from developers other than Microsoft employees, but it's there.
What boilerplate is that? Grain state interfaces are better now, and the Roslyn-based runtime code generator (https://github.com/dotnet/orleans/pull/528) is so close to being merged (so you don't have to include anything in your .csproj, even though that's automatic with the NuGet packages).
I've been really trying to go FOSS (or even OSS) with .NET. But the community does not seem to be very open to it. They do upvote, star or otherwise applaud the effor. Yet nobody uses it. Or even makes the effort to try. My experience with the Python community is quite different. People not only accept the work provided, they actually try and use it and give feedback. It feels good to get a pull request improving something you did. The issue might be that .NET has been promoted as closed source by MS for so long. It might take years before the user base warms up to these new changes.
I work with an entire department of C# developers, and frankly I don't think they care at all about OSS or giving back to the community. It's kind of a bummer, but I've tried to generate enthusiasm around open sourcing some of our components and was met with blank stares.
We've been a Microsoft shop from the start and it's obvious.
How about maybe we've reached a point where there are very few things you can't already do/achieve quite well in C#/.Net without having to dip into OSS land?
I'm a C# dev and I keep close tabs on the plethora of tools that become the new cool thing in OSS for other platforms, and maybe it's a case that I don't work on interesting things...but I've never found myself hindered by C#/.Net.
In any case, the major OSS tools out there do have .Net ports that are actively maintained, perhaps only the bleeding edge stuff is slow on the uptake.
I'm always disappointed when I hear about .Net being open sourced and .Net running on Linux and so on. Because the discussion completely ignores the existence of desktop applications. If you used Winforms or WPF or DirectX, etc. then you're still locked in to the closed source world and Windows only. I know desktop applications aren't cool anymore, but if you were cool, you wouldn't have used .Net in the first place.
> I was incredulous when I couldn’t find a developer-friendly implementation of Murmur3 in C# already.
I've got Murmur3 for you [1] - you can stream into it if that interests you at all. Here's my unit tests [2] (which are arguably the hard part because the reference tests are strange).
I agree with your article, though, a lot needs to be done. E.g. Frustrated with the lack of a .Net diffing lib I went and wrote one based on patience diff [3] and the best I've gotten is one issue. Nobody seems interested in solving problems like the ones you are talking about.
The half-assed actor project mentioned by the article is probably ActorFx - which is an interesting project with some cool ideas. For exammple, you could write actors in a mix of languages like Python, JS, & C#. It had automatic state replication after each turn. Actors were observable, Rx-style. Actor behavior could be specified at runtime: you could effectively throw a JS closure into the cluster and it create an actor out of it.
I wonder, though why it became stagnant so soon and never gained momentum. I'm don't know, but I have a theory. The team were using some tech which was semi-secret at the time, which they weren't allowed to talk about: Service Fabric (known as Windows Fabric at the time). Fabric was in use in projects like Lync Server and Service Bus Server, but no one could talk openly about it.
How can you develop an open-source distributed system without being able to mention the framework which makes it all possible? Fabric handles ActorFx' high availability, service discovery, code distribution/upgrades, and their state replication. It's pretty difficult... Forum posts asking what this fabric thing was went unanswered and the people who may have been interested in ActorFx just moved on.
Regarding Orleans, there were probably a couple of internal actor frameworks in use at some large .NET houses, but they were never released to the public. I think it was more of a cultural issue than a lack of devs: .NET devs weren't used to sharing code.
Things are getting better. The community around Orleans is great (come join us on Gitter! https://gitter.im/dotnet/orleans) and the ecosystem as a whole feels to be gaining momentum.
The issue with this whole argument is you should use the right language for the job instead of trying to recreate the wheel over and over again. Look at Erlang and Elixir if you need highly scalable fault tolerant systems. It doesn't mean you have to re-write everything in it, break up the application into what makes sense. I guess not everyone thinks like I do.
This is a real problem. Not one, but two great open source WPF control libraries I contributed to got 'taken over' (bought out I assume) by a major component seller (XCEED). Of course the community contributions disappeared as the company started selling updates as a pro version with their 'premium' features.
I asked on Twitter long ago for any prominent examples of open source software that originated on Windows and transitioned to other platforms. I think after some discussion we may have come up with an example. Maybe. I certainly can't recall what it was.
And to the other extreme, I know of quite a few open source projects on .NET that have gone proprietary. ServiceStack anyone? Kinda leaves a little bit of a bitter taste in the mouth.
I'm a programmer who started with VB6 on Windows 98 and now I don't even own a partition with Windows installed.
When I programmed VB6 I used to go to Planet Source Code (a website) to see what others had done. There was a lot of beginner code samples being posted which helped newbies like me at the time to learn the ropes. Then there were also a few gems from which I learned a lot over a few weeks of studying the same code base.
Despite my going back there to see what the community was doing, I never thought of PSC as a place where I can find functions I'm missing. I always used the MSDN library for that (it was incredibly helpful with nice examples). In other words, my mental model was: there's VB6 which comes with all functions I'll ever need (it could call any Win32 API function) and then there's PSC where I go hang out with other people that also code VB6 who want to show or share or teach something to the community.
Fast-forward to today - the main language I use at work is Ruby, and it is emblematic of the traits shared by all open-source languages: they do not come with "all functions", in fact most core functions (or what I would consider "core") have been delegated to libraries ("gems" as Ruby calls them). The difference is that my mental model of open-source languages is that they come with barebones functionality and expect the community to contribute with core functions, to the point where basic functionality like HTTP requests have several different libraries modeling the same behavior.
Even though I work solely in open-source languages nowadays, I miss the times where as a programmer I could expect my programming language to be self-sufficient in terms of its environment and its functions. A language should bring as many pre-made functions as possible, and guarantee that they work as expected and amongst each other. I should not be expected to rely on unpaid workers for core functionality, documentation, tooling, etc.
It is a spectrum. On one end (let's call this side "left") you have Small Scheme and Forth and other barebones languages; on the other end (the "right" side of the spectrum) you have giants like SAP and TIBCO. I'd say Ruby leans to the left and VB6 leaned to the right. I'd also pay very good money for a modern, individual-programmer oriented TIBCO-like environment.
Seems to me its more on the people who solve hard problems than on the current crop of .NET developers - if you are writing a complex game/MMO, AI system or what have you, and you choose to do so in Java, C++ or similar when C# might be the better option, the faults on you not the .NET community.
If the whole pool of developers world wide was considered as a big pie, and a certain section of that do these 'hard problems', the solution is to market to them the strengths of .NET. Advocating other parts of the pie who build enterprise apps and who already use .NET that they should suddenly start writing actor systems 'for the good of the framework's OSS cred' seems silly.
As well as a tonne of games in general, which I'd argue are 'hard problems' as well. Pillars of Eternity, Endless Legend etc. Though of course none of those are OSS. Would be nice if at least parts of them were as it would certainly help indie game devs like me :)
What's missing is a .Net, open, powerful CMS à la Drupal 8.
It's hard to understand MS doesn't take this point seriously with its Azure strategy. Orchard CMS is interesting but has little momentum and very few developers.
I think this is just carry over from years ago when many Enterprise level company's legal team would not let you touch or use open source software. Granted this was mostly do to Microsoft's FUD campaigns. Secondly Microsoft provided a licence framework for .net and allowed third parties to sale their solutions. Finally many .net users would wait for microsoft to provide a solution because MS would offer a support and maintenance contract.
Because they'll stick to one solution. For distributed computing most people use something like NServiceBus, which is by far the most popular solution.
Just to add to something I've seen is many places that the Microsoft stack is used open source code is either frowned upon or completely banned. Contributing your (company code) to that is not only against policy but illegal if the company you work for owns the code.
I ran into this when working for the government, CSC, and another company. They developed some cool stuff but just didn't want to share...
Edit: Perhaps this comment is gratuitously negative. Nonetheless I'm not going to delete it because all these things contribute to why people have avoided MS/Windows and hence .NET. (Mono's great and has worked well for me in some scenarios, but, say, with ASP.NET/EF it hasn't been totally stable like the CLR.) I've also invested a ton of time into using MS and promoting them (MVP at one point), so I think I'm rather fair on my criticism.
Don't blame Microsoft? Ha, OK. MS is responsible for gimping the .net environment to Windows with no technical reason. I'm a bit of an MS fanboy but I'll admit deploying on Windows is a pain in the ass. Shit, it's just now they're getting around to "Windows Server Nano'. OpenVZ's been around for a long time, and MS just steadfastly ignored containers as long as they could. Or DRBD - 2015, and MS ships nothing like this. Everything is commercial 3rd party stuff.
Or look at SSH support. It's just now they decided to add that, despite wanting to do it internally for a while. WinRM is annoying but that didn't stop them from leaving it as the only option. And before that? Deployment was what, exposing smb shares?
Or look at IIS. It's 2015, IIS has no real reverse proxy (ARR is a terrible joke), and nginx only runs with limitations on Windows. Why is that? And FFS, they're making you upgrade the OS to have HTTP2, and this whole time, you've not been able to use SPDY. I've seen .net/win shops add Linux just for nginx/SPDY, then realize the grass is greener... Not to mention every other thing, like Elasticsearch - Linux is the OS of choice for deployment, so why bother dealing with it on Windows?
.NET was designed from the beginning to be cross platform and cross language. The first book I read on targeting the CLR was for Component Pascal! The CLR design is far better than the JVM. And around that time, MS had a version of .net running on BSD. They chose to ignore developers and thus everyone flocked to the JVM. This is entirely MS's fault. They could have destroyed Java (or at least started an arms race). The JVM was built solely for Java the language, with no thought for running other languages the CLR was designed explicitly with this in mind, yet almost no langs target the CLR. Explain that without blaming MS.
Even now, they have F#, which is essentially better than C# in every way. How do they promote it? By fucking up features in Visual Studio so things don't quite work. By downplaying it as a language for "scientific" and "financial" work. This is the team that brought generics to .net; without them they'd probably have Java's lameass erasure model. And it looks like MS just grudgingly throws a bit of F# support out as a bone. They don't get it. Instead MS focuses on their line-of-business "Mort" developers. (The kind that can pump out useless, scammy crap to get the Windows Store numbers up, or contribute to more licenses.) They're focused on ops that suit companies that run AD and Exchange. Excellent solutions for those companies; no real focus on others. I'm sure it's been a great win for immediate licenses, but they shouldn't be surprised they lost the war. (And note that via BizSpark, they're giving this stuff away and still can't make it stick.)
And it's not their fault people don't rush to implement code that will possibly only work on Windows? Ha!
(MS has finally shifted to being open towards Linux because they wanna sell overpriced VMs on Azure. And by overpriced, I mean 2x or more of GCE's cost, with none of the perf benefits. And note this was not MS's first choice. They wanted Azure to be a lock-in PaaS, and only when they realised customers didn't want to deal with that mess did they go after IaaS and start "embracing" open source and Linux.)
I apologize for the rant, but I do blame MS for doing all they can to drive developers and ops away from Windows, .Net's only officially supported platform, and thus away from .Net.
You make it sound like the ops for AD and Exchange type businesses is some bad thing. It's a huge installed base. It's massive. they provide revenue. Open source dev stacks build mindshare not direct revenue.
Yes, they were slow to adapt to the changes that happened in the last decade. They seem to be turning it around. Why the emotions?
I didn't mean that to sound bad. Exchange is great! Servicing those customers is smart and fine. But MS focused on them to the point of excluding everyone else, intentionally. (See the SSH announcement, how the tech team tried to do it since v1, but management refused approval.) MS knew they had lock in, went down that path exclusively, and is now trying to catch up because the cool kids left them behind.
I know the latter is a downvotable attitude, and I apologize because it's very unlike me, but it is one of my few sore points, and this comes from years of web developer hell dealing with IE, years of working at places which only considered solutions that Microsoft invented, years of dealing with Microsoft BS left and right.
Lots of downvotes, but I can relate to what you are saying. 10 years of working in a pro Microsoft organization trying to do PHP and Ruby development showed me that developers and managers alike bought into Microsoft's ideas at the time. Microsoft was good, Microsoft offered support, and open-source was just for hobbyists. 10 years of working with servers that were hostile towards openness, and 10 years of watching Microsoft blatantly steal from open-source and not give back.
Now they're giving back. And that's great. But I was involved with IronRuby. And I will never trust MS and open-source after that all went down. I'm a big fan of Chocolatey.org, and I'm hearing that MS wants to do their own version of that too.
I knew I'd get downvotes, but we are real people in a real community and feelings DO matter and have consequences which cannot simply be brushed aside, and those are my honest feelings on it, and I lived through it and saw it all (been a web dev, first frontend now backend, since '97). The last straw was when Microsoft was SO guilty that the judge couldn't help but be biased, which of course caused the antitrust case to get thrown out: http://www.politechbot.com/p-02198.html (note: I'm kind of against antitrust, but I am in favor of SOME punishment when a corporation is provably just being a dick, period).
I also love Ruby (I'm now trying to get into Elixir) so the IronRuby stuff resonates, I salute you.
> and 10 years of watching Microsoft blatantly steal from open-source and not give back
Oh you mean LDAP? ;) And whatever harm Outlook did to MIME or SMTP or... and not even going to mention IE
Just so you know, when I went through college 15 years ago or so and we used open source technologies too. Nobody I went to school with was dying to use whatever vb/asp/iis or jboss server was out there or use windows anything at all.
But, if you get hired at MS and they want you to work on the mssql team, you're not going to recommend they scrap it for mysql.
But there are many places out there that will swap out MySQL or PG for MSQL because it's Microsoft and they all know C#. I had, and have, a really hard time with people who only know the MS way of doing things. I have always taken issue with software developers who only know one language, because I think they're missing out on seeing different ways to look at problems. But the .Net people take it a step further and only look at things from MS. Even if Nancy is a great framework, they wait till WebAPI is available.
And when I've gone to speak at conferences, I'd show things like Sass and livereload, only to have them scoff at me and say "if it isn't in Visual Studio, it's not worth learning." And when VS included live reloading, it was the Greatest Thing Ever.
Just like how ASP.Net MVC came along. People actually argued with me that Microsoft invented that concept. Despite the fact that the very first version looked a lot like a C# version of Rails and Spring.
So that's a chip on my shoulder that I have to get over. Hopefully since the people I know followed MS before, they'll follow them in this new direction.
Hmm... I only experienced one web-technology which was proprietary software and had a strong 'opensource' community, being flash. Always seemed to me, developers using proprietary technologies tend to not share their stuff.
You want to see a weak OSS ecosystem, have a look at Delphi. Truly dire, but not helped by extremely limited modularity and binary incompatibility between versions.
Akka.net wasnt really intended to be a complete port from the start, it was a weekend hack from my part that then grew into what later became akka.net when Aaron joined (akka.actor and akka.remote first).
Then things took off and it got a life of its own.
Now there is an entire sub-ecosystem growing around it in terms of persistence providers, testkits and dependency injection lib integrations.
AWESOME to see :)
To the author: Way to contribute to .NET's image problem with your negative title. If your point is to get more people using .NET then you should have gone with something positive that reflected the last section of your article.
To the mods here: Didn't think to change this one, did you?
> To the mods here: Didn't think to change this one, did you?
We took "profound" out (we often remove superlatives and the like), but I don't see anything else that needs changing here. It isn't gratuitously negative to claim or discuss weakness.
The OSS "weaknesses" of .net are a chicken and an egg problem; the more people who come from a community software background that use a framework, the more community software there will be for that framework.
Having what reads as a very angry and negative blogpost about the state of .net oss isn't really helping.
Contributing software is though, and that really should have been the focus of the post, not how weak and terrible .net oss is.
I hate this attitude that negativity is unproductive. Pointing out a problem, articulating its impacts, and hypothesizing about its causes are essential steps to effective problem solving.
And I further abhor the notion that anger is not useful. Anger gets attention, and passion elicits empathy and thoughtfulness. Anger is motivating. Anger is a rejection of despair, which is the real enemy of change.
Do you respond well when someone yells at you? Honest question.
In a lot of cultures anger is seen as weakness, it's the person giving into negativity. It's also seen as hostile. I don't attribute "passion" to someone who is angry. You can be angry without being passionate, and vice versa. Some people are just bitter.
Of course not. But just because I don't like being yelled at in the moment doesn't mean I don't need it sometimes. If someone's angry at me it's because I've hurt them. I'm not going to scold them for yelling if I'm clearly in the wrong.
> In a lot of cultures blah blah
Thanks for explaining that like I've only recently arrived on Earth! I'm obviously not saying that anger is always good or useful. But if the cause is just and the pain is great, a well-articulated anger is going to be far more effective than milquetoast pleading.
The shortcomings of .NET’s open source ecosystem are your fault and my fault, not Microsoft’s. Do not point the finger at them. Actually, maybe blame them for Windows Server’s consumer-app-hostile licensing model. That merits some blame.
Well, Microsoft itself created a whole ecosystem of the proprietary lock-in type.
Only very recently they seem to jump on the open source bandwagon.
And don't hold your breath for a free software MS office...
There's a different philosophy in the open source world - python, perl, c - none really have 'de facto' answers to persistence, logging, services, etc so There's a plethora of approaches and libraries for any needs. MS provides EF, so you have to defend any alternate solution to business; it's perceived as risky. Even using tools not of MS origin, despite no close surrogate from the 'official' tools (ala Redis, 3rd party libs) is something you have to find approval for. MS tooling is automatically excluded from this. This isn't great for MS either, because they now have to produce these 'ideal' libraries, and the strength of their platform is now judged by library implementations.
I'm really not sure what the solution to this problem is unless they really get to sponsoring projects with effort, money, and tooling. They have programs in place for this, and I can see there's a lot of outreach going on for this reason.