Open Source is a thankless job. We do it anyway.
Sponsored By
Open Source is hard.
Security is hard
There's been lots of articles about the recent OpenSSL "Heartbleed" bug. You can spend a day reading all the technical analysis, but one headline that stood out to me was "OpenSSL shows big problem with open source; underfunded, understaffed." A fundamental part of the fabric of The Internet Itself is mostly just one person plus a bunch of volunteers.
"The fascinating, mind-boggling fact here is that you have this critical piece of network infrastructure that really runs a large part of the Internet, and there’s basically one guy working on it full time."
Moreover, we don't sing contributor's praises for their hard work and success while their software work, instead we wait until a single line (albeit one of the more important lines) fails to live up to expectations. Darn that free stuff, mostly working, and powering our connected global network.
Open Source is largely a thankless job. Sometimes in the Microsoft .NET community, it feels more futile because it's often hard to find volunteers. Many folks use the default stuff, or whatever ships with Visual Studio. With Rails or Node, while they have corporate backing, there's a sense that the projects are community driven. The reality is in-between, but with open source projects built on the Microsoft stack volunteers may say "we'll just use whatever the ship."
There's anger around past actions by Microsoft, but as I've said publicly before, they've come a LONG way. I will keep pushing open source at Microsoft until I think I'm done pushing and can push no more. There's a seismic shift going on inside. Mistakes get made, but it's moving in the right direction. Everyone is learning.
Visibility is hard
Jeremy Miller's team recently stopped active development on the "FubuMVC" open source .NET framework. In his exit blog post, the question of the viability of .NET open source comes up:
"Setting aside the very real question of whether or not OSS in .Net is a viable proposition (it's largely not, no matter how hoarse Scott Hanselman makes himself trying to say otherwise), FubuMVC failed because we — and probably mostly me because I had the most visibility by far — did not do enough to market ourselves and build community through blog posts, documentation, and conference speaking."
It's very true that in a large way visibility drives viability for many open source projects. Jeremy's retrospective is excellent and you should read it.
I think it's harder to bootstrap a large framework project that is an are alternatives to existing large frameworks because for many, it's easier to use the default. Frameworks like FubuMVC, OpenRasta, ServiceStack, Nancy and others all "reimagine the default." They are large opinionated (in a the best way) frameworks that challenge the status quo. But it's much more difficult to cultivate support for a large framework than it is a smaller library like Humanizer or JSON.NET.
Still, without these projects, we'd all still be using the defaults and wouldn't be exploring new ideas and pushing limits as a community like the FAKE F# build system, or Chocolatey, or Boxstarter.
Microsoft can better support OSS projects not just with licenses and money, but with visibility. I'd propose dedicate Open Source tracks at all Microsoft conferences with speaking slots for open source community members. DotNetConf is a start, but we can go bigger.
Organizing is hard
OWIN is an example of a small, but extremely important project that affects the .NET world that is struggling with organization. Getting it right is going to be important for the future. There's a small, but influential group of community members that having been trying for months to find middle ground and build consensus around a technical issue.
ASP.NET Web API and SignalR both build on top of an open source project called OWIN (Open Web Interface in .NET) that aims to decouple servers, frameworks, and middleware from each other.
There's an issue open over on GitHub about what may seems like an obscure but important point about OWIN. The OWIN specification doesn't include an interface called IAppBuilder, but IAppBuilder is used by default in most Microsoft examples. Can the underlying OWIN framework remain neutral? The issue is a long one, and goes off on a few tangents. It's a complex problem that perhaps 20 people fully understand.
Scott Koon worked hard on a Governance document for OWIN and hasn't seen any forward motion. He vented his frustration on Twitter, rightfully so. Under the often-used "Lazy Consensus" technique, if folks are silent or don't reply in 72 hours, that is effectively consent and can change the direction of a project. Active involvement matters.
The fun part of open source is the pull requests and writing code, but before the code building, there's the consensus building. Ownership is the most contentious part of this process. Ownership means control; control over direction. The key to finding control and working through ownership issues is by thoroughly understanding everyone's differing goals and finding a shared vision that the community can rally around, then move forward.
This sausage making process is tedious, messy, but necessary. These discussions are as much a part of OSS as the code is. It takes equal parts patience and pushing.
Getting involved is hard
I get dozens of emails every week that all ask "how can I get involved in open source?" Everyone assumes my answer will be "write code" or "send a pull request," or sometimes, "help write documentation."
In fact, that's not all you can do. What you can do is read. Absorb. Understand. Be welcoming, inclusive, and kind. Offer thoughtful analysis and ask questions. Avoid hyperbole and inflammatory language. Show code examples when commenting on issues. Be helpful.
Your blog posts are the engine of community, your open source commits, documentation, promotion, samples, talks, gists are important. But getting involved in open source doesn't always mean "fork a project and send a giant pull request with your worldview." Sometimes it's the important but unglamorous work of writing a governance document, organizing a conference call, or thoroughly reading a giant Github issue thread before asking a question.
Why do we do this? It's not for the glamour or the money. It's because we are Builders. I encourage you all to get involved. There's lots to be done.
* photo by Sweet Chili Arts, used under CC
Sponsor: Big thanks to Novalys for sponsoring the blog feed this week! Check out their security solution thatcombines authentication and user permissions. Secure access to features and data in most applications & architectures (.NET, Java, C++, SaaS, Web SSO, Cloud...). Try Visual Guard for FREE.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
April 13, 2014 19:35
Yep, a fun set of challenges. The other tricky issue is the sense of entitlement. Meaning: if you *do* manage to get users, some will want some complicated but extreme minority feature, and don't seem to understand that this doesn't just happen overnight, or that any extra features just for them is a whole extra set of code that will need maintenance and regression testing forever. Or who will bemoan that there isn't an example document describing exactly their scenario, but who also don't want to help by... writing one. It can also be rewarding; but it has moments when it sucks.
Marc Gravell
Marc - Entitlement is a huge issue. Folks don't realize that changing something can "break the world." Also, I've seen large enterprises elect to NOT use an open source project because the college student that maintains it is moving on.
There's anger around past actions by Microsoft, but as I've said publicly before, they've come a LONG way. I will keep pushing open source at Microsoft until I think I'm done pushing and can push no more.
As someone who is generally pretty negative towards Microsoft, probably too often, I can honestly say MS has definitely come a long way over the last 2 years. Lots of great things have happened, and I hope it continues.
Thank you Scott and all those at Microsoft who have helped make these changes happen!
Because it is so hard to have an Open Source project work as expected, in all terms, there should be a new approach on how a project is funded. At my blog, I wrote: Had Heartbleed showed us a new business model for Open Source?.
I ask the reader to answer a question:
"if we, the IT industry, had put more investment into the OpenSSL development team, would the chances had been higher for the Heartbleed bug to be found?"
Which leads to a very simple question:
Should we consider a different business model for Open Source software? What about a model where a company (not individual) willing to use an Open Source software has to either:
What are your thoughts?
I ask the reader to answer a question:
"if we, the IT industry, had put more investment into the OpenSSL development team, would the chances had been higher for the Heartbleed bug to be found?"
Which leads to a very simple question:
Should we consider a different business model for Open Source software? What about a model where a company (not individual) willing to use an Open Source software has to either:
- pay for a license and/or subscription support;
- provide resources (developers and/or QA) dedicated to the software itself;
What are your thoughts?
@Bruno There are already people out there doing this kind of thing. For example RRDTool, an open source time-series database and graphing suite (it might compete with commercial efforts from OSISoft - PI,AF etc) and corporate entities sponsor new feature development as well as open support contracts. So, it seems to work, but this greatly depends on the people in those corporate entities understanding open source software.
http://oss.oetiker.ch/rrdtool/sponsor.en.html
http://oss.oetiker.ch/rrdtool/sponsor.en.html
@Bruno Doing that just stops it being open source. There's already software out there you can pay for; you're just taking open source and making it not open. Allowing contribution of resources is just another way of paying for it.
If someone is putting constraints on their software; someone else will do the same software without the constraints. We're developers; that's what we do. We write code; regardless of whether someone's paying us for it. If the only software that does X is not free/OSS; then some dev that wants to code will fill that hole in the "market". How many pieces of strings-attached software can you think of that don't have an OSS alternative?
Personally; I don't think the quality of software is in any way related to whether it's OSS or not. Commercial software can be unloved, abandoned, badly managed and poorly reviewed/tested too. You could say commercial software is better because a companies business depends on it; but you could also say OSS is better because the developers are doing it for the love of building the product without financial motivation or constraits.
I don't think any amount of additional funding in OpenSSL would have ruled out a bug like Heartbleed; a bug is a bug; it would've been found with more testing or reviewing. More funding would probably just add more features; not verify the correctness of the old ones. People take OSS software and make assumptions about it without reviewing/testing it. This isn't the first widespread security bug, nor will it be the last.
If we want to improve the quality of open source software; we don't need to put funding into all of the projects, we need to do the same things to improve the quality of closed source software; and that is to improve tools, languages, etc. so that developers are better able to write and prove correct software.
Developers are starting to focus more and more on concurrent and parallel code; yet the languages and frameworks we use make it easy to write code full of race conditions. Putting funding into solving these problems will benefit both open source and closed source projects at a much larger scale than funding for individual projects.
If someone is putting constraints on their software; someone else will do the same software without the constraints. We're developers; that's what we do. We write code; regardless of whether someone's paying us for it. If the only software that does X is not free/OSS; then some dev that wants to code will fill that hole in the "market". How many pieces of strings-attached software can you think of that don't have an OSS alternative?
Personally; I don't think the quality of software is in any way related to whether it's OSS or not. Commercial software can be unloved, abandoned, badly managed and poorly reviewed/tested too. You could say commercial software is better because a companies business depends on it; but you could also say OSS is better because the developers are doing it for the love of building the product without financial motivation or constraits.
I don't think any amount of additional funding in OpenSSL would have ruled out a bug like Heartbleed; a bug is a bug; it would've been found with more testing or reviewing. More funding would probably just add more features; not verify the correctness of the old ones. People take OSS software and make assumptions about it without reviewing/testing it. This isn't the first widespread security bug, nor will it be the last.
If we want to improve the quality of open source software; we don't need to put funding into all of the projects, we need to do the same things to improve the quality of closed source software; and that is to improve tools, languages, etc. so that developers are better able to write and prove correct software.
Developers are starting to focus more and more on concurrent and parallel code; yet the languages and frameworks we use make it easy to write code full of race conditions. Putting funding into solving these problems will benefit both open source and closed source projects at a much larger scale than funding for individual projects.
"Open Source" software doesn't have to be free as in free beer. Obligating companies to pay for a project, either by giving money so the foundation can invest by hiring full-time developers, or by giving their own developers to work full-time on these Open Source projects would drastically increase the amount of people coding, improving, reviewing, testing, etc. People love to code, yes. But love isn't enough in the world we live in, sadly. Open Source should not be charity.
Charging for an Open Source project also does not remove the "Open Source" nature. It will continue to be open, but not 'free' for companies who profit from it; only individulas should be free to use it. If there is profit, there should be a trade. Unfortunately, as you might agree, the way a great part of the IT industry sees Open Source projects is just "Free" software to run for-profit business.
There should be a way to avoid that, while keeping freedom for individuals to use, contribute back, and be part of Open Source projects.
Charging for an Open Source project also does not remove the "Open Source" nature. It will continue to be open, but not 'free' for companies who profit from it; only individulas should be free to use it. If there is profit, there should be a trade. Unfortunately, as you might agree, the way a great part of the IT industry sees Open Source projects is just "Free" software to run for-profit business.
There should be a way to avoid that, while keeping freedom for individuals to use, contribute back, and be part of Open Source projects.
@Bruno But what you're suggesting is a barrier to using the software for several reasons, including:
1. Some companies simply won't be prepared to spend the money
2. The people that make the decision to use open source software/libraries currently (for example, developers) often cannot take the decision to a) pay or b) commit resources alone. Getting this "agreement" may be tough and/or take time. Many devs will simply take an alternative rather than embark on this "mission" because thy're probably knee deep in solving a complex problem.
There will almost certainly always be someone willing to do it completely free. Some devs (myself included) would simply rather our software was used by as many people as possible. Adding barriers will be counter-productive to that goal.
I have no cares of being rewarded for anything done in my spare time, and I'm certainly not alone. Because of this, (really) free alternatives will almost always exist, and limit the use of not-quite-open-source software as described.
I'd go as far as saying that payment-required open source gets the worst of both worlds; it costs money and it doesn't have a solid business backing it. I'd rather have something free-and-on-my-head or paid-but-I-have-someone-to-kick-if-its-bad.
1. Some companies simply won't be prepared to spend the money
2. The people that make the decision to use open source software/libraries currently (for example, developers) often cannot take the decision to a) pay or b) commit resources alone. Getting this "agreement" may be tough and/or take time. Many devs will simply take an alternative rather than embark on this "mission" because thy're probably knee deep in solving a complex problem.
There will almost certainly always be someone willing to do it completely free. Some devs (myself included) would simply rather our software was used by as many people as possible. Adding barriers will be counter-productive to that goal.
I have no cares of being rewarded for anything done in my spare time, and I'm certainly not alone. Because of this, (really) free alternatives will almost always exist, and limit the use of not-quite-open-source software as described.
I'd go as far as saying that payment-required open source gets the worst of both worlds; it costs money and it doesn't have a solid business backing it. I'd rather have something free-and-on-my-head or paid-but-I-have-someone-to-kick-if-its-bad.
// 1. Some companies simply won't be prepared to spend the money
This will be a matter of price/negotiation. The foundation or the company behind an Open Source project will define the requirements. If it is too expensive, or requires too many developers working part/full-time to back the project, other foundations/companies will come up with alternative solutions, negotiable options. All I'm saying is that none should actually offer for free. Competition will continue to exist though.
If there are individuals willing to do completely free, fine. But businesses and those who want to run a business (get paid, or invest enough time/resources) on top of Open Source projects, these businesses should reconsider the business model.
Companies/foundations willing to run a serious Open Source project should stop the "please support us, please subscribe our support offer, please donate" stuff. It should be "pay, or give us paid developers; it will be for your own good".
This will be a matter of price/negotiation. The foundation or the company behind an Open Source project will define the requirements. If it is too expensive, or requires too many developers working part/full-time to back the project, other foundations/companies will come up with alternative solutions, negotiable options. All I'm saying is that none should actually offer for free. Competition will continue to exist though.
If there are individuals willing to do completely free, fine. But businesses and those who want to run a business (get paid, or invest enough time/resources) on top of Open Source projects, these businesses should reconsider the business model.
Companies/foundations willing to run a serious Open Source project should stop the "please support us, please subscribe our support offer, please donate" stuff. It should be "pay, or give us paid developers; it will be for your own good".
Economists know this phenomenon well as the 'tragedy of the commons'.[1] OSS is a public good which everyone wants to use, but no one wants to pay for.
[1] http://en.wikipedia.org/wiki/Tragedy_of_the_commons
[1] http://en.wikipedia.org/wiki/Tragedy_of_the_commons
I think it's harder to bootstrap a large framework project that is an are alternatives to existing large frameworks because for many, it's easier to use the default.
Definitely agree with that one. I worked on one site where we used the Spark view engine with ASP.NET MVC, but that's probably the only occasion of using a piece of open source that just flat-out replaced a significant piece of the "default" ASP.NET stack.
It's tough to push something like that in a business environment because you are making it more difficult for new people on the team in the future, it is the path of least resistance to use the default components (especially given that, imho, they really are very good).
But add-on components, I don't see any shortage of them getting used. Everyone is using their ELMAHs and NLogs and what-have-yous.
What you guys are debating shows there are down sides to both models, but the reason I give the edge to open source, despite all of the pitfalls that Scott talks about, is that it does move us forward and generally improves the .NET developer scene. I've had maybe three kudos from people who use POP Forums over the last year, but I do it because it's the closest thing I can do to contribute to the other projects it depends on.
And I think that might be one of the issues, and it's not unique to .NET: Everyone hopes their project will become a phenomenon. Honestly I think there are too many people trying to write frameworks that cure cancer, or take a slightly different approach on a problem that's already pretty well covered. There's nothing wrong with maintaining something that is a bit of a niche or has a small audience.
I for one am excited by all of the projects out there, and this robustness is what makes it fun to code on this stack.
And I think that might be one of the issues, and it's not unique to .NET: Everyone hopes their project will become a phenomenon. Honestly I think there are too many people trying to write frameworks that cure cancer, or take a slightly different approach on a problem that's already pretty well covered. There's nothing wrong with maintaining something that is a bit of a niche or has a small audience.
I for one am excited by all of the projects out there, and this robustness is what makes it fun to code on this stack.
The problem with the "Open Source is Secure" paradigm is that it assumes that every line of code is being properly peer-reviewed by the community. It's not. Code reviews are tedious and boring. The only reason it gets done in commercial software is because people pay us money to do it.
As developers, we *hate* QA. We *hate* code reviews. We want to be writing code, not checking over someone elses. Open Source shows a strong propensity towards lots of developers writing software but then easily glossing over the QA/review processes because A) lack of manpower and B) lack of will.
I don't see how this problem can be easily overcome.
As developers, we *hate* QA. We *hate* code reviews. We want to be writing code, not checking over someone elses. Open Source shows a strong propensity towards lots of developers writing software but then easily glossing over the QA/review processes because A) lack of manpower and B) lack of will.
I don't see how this problem can be easily overcome.
On the desktop-side, it's hard to get motivated to start a project. Silverlight - gone. WPF - on its way. I've held off any Windows Store projects/libraries because my money is on it being relegated to the dust-heap as well (with Sinofsky).
What is more shocking, that a one-man-band library had a security hole in it, or that massive multi-national, professional institutions didn't contribute anything back?
That linked article pointing out the "problem" with open source is extremely narrow-minded and is, in my view, actually perpetuating what the true problems are: perception: people wanting something for nothing; people pulling in updates without code review; people not patching mistakes even though they use the software; and finally, blaming the author's opinion on how to run the library he started!
What scares mre the most is this library existing in many a large company's testing framework and going through security analysis only to be deemed safe. They missed this security hole for two years too! Don't blame the guy who started this, he has no sole responsibility over where it is used, how and by whom - everybody who uses it does.
That linked article pointing out the "problem" with open source is extremely narrow-minded and is, in my view, actually perpetuating what the true problems are: perception: people wanting something for nothing; people pulling in updates without code review; people not patching mistakes even though they use the software; and finally, blaming the author's opinion on how to run the library he started!
What scares mre the most is this library existing in many a large company's testing framework and going through security analysis only to be deemed safe. They missed this security hole for two years too! Don't blame the guy who started this, he has no sole responsibility over where it is used, how and by whom - everybody who uses it does.
If an open source .NET community is what you want, then you need to build around an open source runtime implementation.
Why aren't more people switching to Mono? Miguel has said himself that he would like to see it used server side (not just as a unifying mobile language tool). I've experimented with a few projects using Mono on Linux and have found it to show great promise.
That said, some of the existing open source .NET projects are either painfully disorganised (OWIN) or have absolute trolls at their helm and are impossible to reason with when trying to suggest improvements (Nancy).
The community does want to exist. I can see it trying to come to life. There are just a few fundamental pieces that have yet to fall into place. I wasn't nothing more than to write C# on Linux... For a living if possible ;)
Why aren't more people switching to Mono? Miguel has said himself that he would like to see it used server side (not just as a unifying mobile language tool). I've experimented with a few projects using Mono on Linux and have found it to show great promise.
That said, some of the existing open source .NET projects are either painfully disorganised (OWIN) or have absolute trolls at their helm and are impossible to reason with when trying to suggest improvements (Nancy).
The community does want to exist. I can see it trying to come to life. There are just a few fundamental pieces that have yet to fall into place. I wasn't nothing more than to write C# on Linux... For a living if possible ;)
For the average person that know nothing about open source or even the concept of community, he will be doomed to such pity surprise as "what ? only one person, not even paid is behind Open SSL" (And imagine when I explain that the creator of bitcoin is not even know and used the pseudo of Satoshi)
The developer community knows more about the reason, and understand that such bug might occur even with 100 persons reviewing the code. Our software fails, that's a fact of life we understand, and we know it will not be the last time. We can decrease the probability with some practice but never supress it.
We should educate the mass by telling them their internet provider is not the one that created internet and that internet is a gigantistic piece of garbage turned masterpiece fueled more by the passion of the builders than money. (This not so easy to understand, since our work is one of the only one that can be done freely at home, without any formal education and graduation)
We don't care about the reaction of the mass though, open ssl is used by IT people that understand that, and while there is no viable economic alternative, the negative remarks are nothing but cheap words.
The developer community knows more about the reason, and understand that such bug might occur even with 100 persons reviewing the code. Our software fails, that's a fact of life we understand, and we know it will not be the last time. We can decrease the probability with some practice but never supress it.
We should educate the mass by telling them their internet provider is not the one that created internet and that internet is a gigantistic piece of garbage turned masterpiece fueled more by the passion of the builders than money. (This not so easy to understand, since our work is one of the only one that can be done freely at home, without any formal education and graduation)
We don't care about the reaction of the mass though, open ssl is used by IT people that understand that, and while there is no viable economic alternative, the negative remarks are nothing but cheap words.
Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.
-Kurt Vonnegut
-Kurt Vonnegut
Sometimes in the Microsoft .NET community, it feels more futile because it's often hard to find volunteers
My understanding of things may be outdated, but I think that's because .NET itself and the main tool to author .NET code, Visual Studio, are not really cross-platform and are also meant to run on a commercial platform (that will probably never be open source).
Sure, you can open-source anything you want and welcome contributions, however the fact that in order to do that, you:
Really impedes things here. Please correct me if I'm wrong.
Dmitry,
That really hasn't been true since Monodevelop. I've worked on several projects where I windows users were in the minority, but we were all using Mono and Monodevelop to allow for cross-platform development.
Both Unity and Xamarin have leveraged this to offer their own flavors of mono-develop as their default development platform and offer Visual Studio as a paid for or alternate option.
That really hasn't been true since Monodevelop. I've worked on several projects where I windows users were in the minority, but we were all using Mono and Monodevelop to allow for cross-platform development.
Both Unity and Xamarin have leveraged this to offer their own flavors of mono-develop as their default development platform and offer Visual Studio as a paid for or alternate option.
Must buy and use Windows
Must buy and use Visual Studio
Probably need to pay extra for a Windows hosting
Actually the majority of .NET OSS projects I've seen on GitHub have instructions for building/developing with VS as well as with Mono/SharpDevelop/InsertOtherToolOrPlatformHere. I've seen people who only write their C# code in SublimeText.
As for the hosting in Windows, that part is largely still true today if you're doing an ASP.NET app, but that's part of the point of OWIN - the decoupling from the IIS/Windows world.
Really, you can work pretty much any way you want - but as Scott points out, the issue is that it isn't as simple as it would be if you just run VS on Windows and use the defaults.
Dmitry,
Windows hosting does tend to cost a little more. Arvixe, for example, provides Linux and Windows hosting, and entry level Windows hosting costs $1 more per month than the equivalent entry level Linux plan. Paying an extra $12 per year to be able to use the tools I'm most familiar with is worth it for me.
Windows hosting does tend to cost a little more. Arvixe, for example, provides Linux and Windows hosting, and entry level Windows hosting costs $1 more per month than the equivalent entry level Linux plan. Paying an extra $12 per year to be able to use the tools I'm most familiar with is worth it for me.
What could be considered the central rally point for open source .NET? Is it ohloh? What about news?
When I worked with Drupal I found that I felt part of a community and I think that feeling, at least in part, could be attributed to having a drupal.org login and being able to change and contribute to pretty much anything on that site.
I don't know where to go for that with .NET. There's Github, StackOverflow, CodePlex, NuGet and ASP.NET, but none of them gives me that holistic "I'm part of the .NET open source ecosystem" feeling.
When I worked with Drupal I found that I felt part of a community and I think that feeling, at least in part, could be attributed to having a drupal.org login and being able to change and contribute to pretty much anything on that site.
I don't know where to go for that with .NET. There's Github, StackOverflow, CodePlex, NuGet and ASP.NET, but none of them gives me that holistic "I'm part of the .NET open source ecosystem" feeling.
@JeremyCook what's sad is that I think CodePlex, Nuget and even Chocolately are supposed to provide that community, but they fall short. And I don't think it's their fault. I think it's mostly the software and licensing when dealing with the Microsoft stack. Getting up and running requires you to install so many things - Windows, .NET, VS, service packs - and 2 of those cost a significant amount of money. Why develop open source software when you can't acquire the tools for free?
No matter what Microsoft is trying to do with the .NET Foundation the fact is .NET is still their software and everyone has to play by their rules. Open source implementations like Mono will never be in the forefront because of this - they're forced to follow.
No matter what Microsoft is trying to do with the .NET Foundation the fact is .NET is still their software and everyone has to play by their rules. Open source implementations like Mono will never be in the forefront because of this - they're forced to follow.
My head is full with thoughts after reading this. Most of my day is filled working in Open Source on .net in one way or another (coding or related benevolent activities). And I'm still on the fence whether it has a long term future. Frankly I don't think anything is likely to change any time soon. O/S remains the work of individuals that feel compelled for one reason or another to pull a specific project forward. And this is always a temporary affair. We have some new tools to help with continuity: Github makes it easier to pick up someone else's project and move on with it. And kickstarter type sites make it easier to raise money for "good ideas".
My pitch for O/S is that despite the drawbacks it is still a good option for everyone. If continuity is your concern: how many times do read about commercial products getting axed? Or failing? Or being destroyed by a new corporation that bought the product? Just as often, I'd say.
My pitch for O/S is that despite the drawbacks it is still a good option for everyone. If continuity is your concern: how many times do read about commercial products getting axed? Or failing? Or being destroyed by a new corporation that bought the product? Just as often, I'd say.
Working on an OSS project can definitely be frustrating - narrow minded entitlement (I need this feature now!) and arrogance (this is the most important thing ever, you are just too stupid to understand!) can be tough to take. As can biased and negative blog posts/tweets, especially when they're factually incorrect, but you have to try and be thick skinned and move on (the emphasis being on try :-))
In my experience though, those things are pretty few and far between, and are far outweighed by the positives. I can still remember the buzz when I setup a Google alert on my first OSS project and saw people actually start using it, and the first Pull Request you get from some random person you've never spoken to is just amazing ( and it's still a buzz, even over 100 people later: http://nancyfx.org/contribs.html )
My initial involvement in OSS came from two things, firstly wanted to scratch an itch to write something I felt was needed at the time, and secondly to try and recapture some "developer mojo" from working on some particularly tedious work related code. I'm a firm believer in the latter being a major issue in day to day .net dev, which is one of the reasons why I found myself drawn to the Nancy project in the first place.
As things grow you get another set of problems, albeit good problems - it becomes much harder to keep on top of communications, and you can get so swamped with contributions that it feels like you never actually get to code anything yourself. Both of these issues are solvable by either a) going full time - which isn't an option outside of a very lucky few, or b) scaling out by trying to foster a community.
It's the latter that we have tried to do with Nancy, and while we're far from perfect at it, we've managed to get a great community around the project (as much by accident as intention). The community side is brilliant - it's equally as much a buzz when someone who's not a regular in the project answers questions on StackOverflow/Jabbr as it was when we got our first pull request. The Nancy MVM program ( http://nancyfx.org/mvm.html ) was a page I threw together as a tongue in cheek joke about the MVP program, but since then it's become a really great set of people who genuinely care about the product and share the vision, and that Andreas and I owe a huge amount of gratitude to.
So, TL;DR - yes Open Source can sometimes feel like a thankless task, and sometimes it's hard to not take some comments personally, but it can also be massively rewarding and I, for one, certainly wouldn't want to give it up. It can be daunting open sourcing code or getting involved in a project for the first time (what if my code sucks? what if I get ripped to pieces?), but it's definitely something I'd recommend everyone try and get involved in - sure, sometimes people can be dickish, but the personal rewards can be amazing.
In my experience though, those things are pretty few and far between, and are far outweighed by the positives. I can still remember the buzz when I setup a Google alert on my first OSS project and saw people actually start using it, and the first Pull Request you get from some random person you've never spoken to is just amazing ( and it's still a buzz, even over 100 people later: http://nancyfx.org/contribs.html )
My initial involvement in OSS came from two things, firstly wanted to scratch an itch to write something I felt was needed at the time, and secondly to try and recapture some "developer mojo" from working on some particularly tedious work related code. I'm a firm believer in the latter being a major issue in day to day .net dev, which is one of the reasons why I found myself drawn to the Nancy project in the first place.
As things grow you get another set of problems, albeit good problems - it becomes much harder to keep on top of communications, and you can get so swamped with contributions that it feels like you never actually get to code anything yourself. Both of these issues are solvable by either a) going full time - which isn't an option outside of a very lucky few, or b) scaling out by trying to foster a community.
It's the latter that we have tried to do with Nancy, and while we're far from perfect at it, we've managed to get a great community around the project (as much by accident as intention). The community side is brilliant - it's equally as much a buzz when someone who's not a regular in the project answers questions on StackOverflow/Jabbr as it was when we got our first pull request. The Nancy MVM program ( http://nancyfx.org/mvm.html ) was a page I threw together as a tongue in cheek joke about the MVP program, but since then it's become a really great set of people who genuinely care about the product and share the vision, and that Andreas and I owe a huge amount of gratitude to.
So, TL;DR - yes Open Source can sometimes feel like a thankless task, and sometimes it's hard to not take some comments personally, but it can also be massively rewarding and I, for one, certainly wouldn't want to give it up. It can be daunting open sourcing code or getting involved in a project for the first time (what if my code sucks? what if I get ripped to pieces?), but it's definitely something I'd recommend everyone try and get involved in - sure, sometimes people can be dickish, but the personal rewards can be amazing.
I have never been a big fan of open source unless the project is invested and has actual quality control. I don't know how many times I have been burned by "Lets use this open source project because its free!" Then it has some major flaw that we don't have the time to figure out and end up having to ditch it and go with a paid solution anyway. And even if we could fix it, self-fixing open source breaks upgrade compatibility (if the dev ever decides to write a new version).
I'll use stylecop and visual studio 2013 as an example. When VS2013 came out stylecop would not install for it. We were forced to wait to upgrade because stylecop was used heavily. And it wasnt like we had to only wait a few days, we had to wait weeks to a month. Call it entitlement if you will but being able to upgrade to next major of version of visual studio I would have thought would have been a big deal. If it were a paid product you can bet it would have supported vs2013 out of the box.
There is also a reverse sense of entitlement I see from open source developers. JSON.NET for example. There is a major problem where if you put an int into a property of type Object and deserialize in a .net client it comes out as a long and breaks everything that does casting. It has been pointed out to the project many times by many people and the answer has been "I think it would make the json messy so im just not going to do it and you just have to deal with it". We literally had to write our own json converter that encoded the value types into it which breaks third party integration even more. If you look at fastJSON the guy goes "yep I know its a problem, and here is the solution! thanks for using me". This wasn't a case of "ill get to it when I can" its a case of "I don't think you should do it so im just not going to support it" instead of being "Yeah I see this is a major flaw and while I think it will end up bloating the json I understand that it breaks almost every .net client consumer in some way so ill support the opt in for it".
Maybe I just have experienced isolated instances but like if I had used fubumvc I would be PISSED. We used knockout for a project right before angular came out. All of a sudden knockout almost entirely disappeared overnight. Boy did we feel stupid investing all that time and money just to have it swept under the rug because some other new open source thing came out.
Long live paid software!
I'll use stylecop and visual studio 2013 as an example. When VS2013 came out stylecop would not install for it. We were forced to wait to upgrade because stylecop was used heavily. And it wasnt like we had to only wait a few days, we had to wait weeks to a month. Call it entitlement if you will but being able to upgrade to next major of version of visual studio I would have thought would have been a big deal. If it were a paid product you can bet it would have supported vs2013 out of the box.
There is also a reverse sense of entitlement I see from open source developers. JSON.NET for example. There is a major problem where if you put an int into a property of type Object and deserialize in a .net client it comes out as a long and breaks everything that does casting. It has been pointed out to the project many times by many people and the answer has been "I think it would make the json messy so im just not going to do it and you just have to deal with it". We literally had to write our own json converter that encoded the value types into it which breaks third party integration even more. If you look at fastJSON the guy goes "yep I know its a problem, and here is the solution! thanks for using me". This wasn't a case of "ill get to it when I can" its a case of "I don't think you should do it so im just not going to support it" instead of being "Yeah I see this is a major flaw and while I think it will end up bloating the json I understand that it breaks almost every .net client consumer in some way so ill support the opt in for it".
Maybe I just have experienced isolated instances but like if I had used fubumvc I would be PISSED. We used knockout for a project right before angular came out. All of a sudden knockout almost entirely disappeared overnight. Boy did we feel stupid investing all that time and money just to have it swept under the rug because some other new open source thing came out.
Long live paid software!
"If it were a paid product you can bet it would have supported vs2013 out of the box."
A very expensive tool, which will remain nameless, released their VS2013 support about 2 weeks ago - so paying for it is no guarantee of expediency :)
Also your comment about Fubu doesn't make any sense - Jeremy is stepping down, but the code is open so someone could step up and carry on moving it forwards. Compare that to something like Windows Live Writer, or any of the technologies that Microsoft has abandoned (even though will never admit things are dead) and you're very much stuck.
So, yes, saying you'd be "pissed" about the lead dev on Fubu stepping down is both oddly blinkered, and given your apparent lack of any contribution, would be quite a good example of the entitlement people have spoken about.
Each to their own.
A very expensive tool, which will remain nameless, released their VS2013 support about 2 weeks ago - so paying for it is no guarantee of expediency :)
Also your comment about Fubu doesn't make any sense - Jeremy is stepping down, but the code is open so someone could step up and carry on moving it forwards. Compare that to something like Windows Live Writer, or any of the technologies that Microsoft has abandoned (even though will never admit things are dead) and you're very much stuck.
So, yes, saying you'd be "pissed" about the lead dev on Fubu stepping down is both oddly blinkered, and given your apparent lack of any contribution, would be quite a good example of the entitlement people have spoken about.
Each to their own.
Someone could pick it up doesn't mean someone will pick it up. And if my boss being upset at having to spend hundreds of thousands of dollars refactoring out of a framework that might not ever be supported and me losing my job over picking it is entitlement then call me entitled
Whereas all those bosses presiding over hugely expensive public Silverlight projects a few years back would be all kittens and rainbows about their longevity...
I really don't know how people find the time to work on and keep these open source projects going. I always feel like I'm treading water trying to keep up with the "latest and greatest" and if and how to apply new technologies at my current work. It's all "it's all web forms. now we're doing mvc. jquery. knockoutjs. angularjs. nosql. ef. signalr. responsive design. owin." It is A LOT to consume so at the end of the day when Visual Studio ships with jQuery, twitter bootstrap, has it's own MVC framework you can be sure that something like FubuMVC better be mindblowingly better than ASP.NET MVC framework for me to switch to it. And don't get me started on another custom MVC view engine. I really appreciate these people working on open source projects but it's a tough task to get enough visibility to get "buy in" at larger companies or companies with large code bases.
"We used knockout for a project right before angular came out. All of a sudden knockout almost entirely disappeared overnight. Boy did we feel stupid investing all that time and money just to have it swept under the rug because some other new open source thing came out."
what happened to Knockout?
what happened to Knockout?
Like Filip, I am wondering what supposedly happened to Knockout....we still use Knockout extensively in our project, because it's great for us and we made the conscious decision not to always jump on the "latest and greatest" thing unless our analysis showed that there was a definite business case (read: money saved) for it.
So why would you abandon Knockout just because Angular came along? Knockout has certainly not gone away and is still very much an a popular framework. Even if it weren't - I'd still be happy to use it, knowing that if I came across any zingers, I can have a go at fixing it myself.
When you decide to use an OSS project, especially in a commercial scenario, I really think you have to take on some responsibility:
- You must ensure that the project will cover your needs right now, as-is and without the involvement of the creator
OR
- You take on the responsibility to modify the code to suit your specific needs as you discover places where it doesn't quite fit (or indeed has bugs) and then in the spirit of OSS you contribute those modifications back to the community in case anyone else might find them useful. You also accept the possibility that your contributions might not be deemed suitable for inclusion in the main product branch.
Personally I think that's one of the main points of OSS. With a closed source solution you do not even have the second option, and are at the mercy of the vendor. Granted, if the paid-for product turns out to be a lie, then you have a case for getting your money back, but you still haven't delivered *your* product. I'd rather have a fighting chance of being able to fix a framework myself and deliver a working solution to my customers :)
So why would you abandon Knockout just because Angular came along? Knockout has certainly not gone away and is still very much an a popular framework. Even if it weren't - I'd still be happy to use it, knowing that if I came across any zingers, I can have a go at fixing it myself.
When you decide to use an OSS project, especially in a commercial scenario, I really think you have to take on some responsibility:
- You must ensure that the project will cover your needs right now, as-is and without the involvement of the creator
OR
- You take on the responsibility to modify the code to suit your specific needs as you discover places where it doesn't quite fit (or indeed has bugs) and then in the spirit of OSS you contribute those modifications back to the community in case anyone else might find them useful. You also accept the possibility that your contributions might not be deemed suitable for inclusion in the main product branch.
Personally I think that's one of the main points of OSS. With a closed source solution you do not even have the second option, and are at the mercy of the vendor. Granted, if the paid-for product turns out to be a lie, then you have a case for getting your money back, but you still haven't delivered *your* product. I'd rather have a fighting chance of being able to fix a framework myself and deliver a working solution to my customers :)
@flogmeifyouwill,
"I have never been a big fan of open source unless the project is invested and has actual quality contro"
The FubuMVC ecosystem has somewhere in the neighborhood of 6-7000 automated tests and I'd put our technical quality against any other OSS framework and anything from Redmond. We worked continuously for over five years and had a couple hundred contributors over the years and across all the tools. The very folks in this case who would be "pissed" that the project is shutting down are the very same folks that didn't participate enough to keep things going.
The thing about fubu shutting down that should concern Hanselman and Microsoft itself is that many of the people who were most active earlier on have lost interest in .Net itself, and it's a little bit hard to run an OSS community of folks that don't believe in the underlying platform.
"FubuMVC better be mindblowingly better than ASP.NET MVC framework for me to switch to it"
ASP.Net MVC is a highly flawed framework that was rushed out the door too quickly because Microsoft desperately needed to plug a hole in its offerings because they waited way too long to admit that WebForms day had passed. .Net would be a much better place if alternative approaches could find a bit more purchase and support. Microsoft would make better tools themselves if they had any real competition within the .Net space to sharpen up their own offerings.
"I have never been a big fan of open source unless the project is invested and has actual quality contro"
The FubuMVC ecosystem has somewhere in the neighborhood of 6-7000 automated tests and I'd put our technical quality against any other OSS framework and anything from Redmond. We worked continuously for over five years and had a couple hundred contributors over the years and across all the tools. The very folks in this case who would be "pissed" that the project is shutting down are the very same folks that didn't participate enough to keep things going.
The thing about fubu shutting down that should concern Hanselman and Microsoft itself is that many of the people who were most active earlier on have lost interest in .Net itself, and it's a little bit hard to run an OSS community of folks that don't believe in the underlying platform.
"FubuMVC better be mindblowingly better than ASP.NET MVC framework for me to switch to it"
ASP.Net MVC is a highly flawed framework that was rushed out the door too quickly because Microsoft desperately needed to plug a hole in its offerings because they waited way too long to admit that WebForms day had passed. .Net would be a much better place if alternative approaches could find a bit more purchase and support. Microsoft would make better tools themselves if they had any real competition within the .Net space to sharpen up their own offerings.
We didn't change off of knockout. We couldn't afford to. And by dissapeared I'm mainly talking about community buzz and support. I can't even remember the last time I saw a knockout article or even anyone mentioning the word knockout in a technical conversation. And a lot of business managers over technical organizations pay attention to the buzz and then question the semi-recent adoption of something that they now perceive as outdated. Not all of them are like this but I have literally had a situation where funds were directed at removing all of the distinct clauses in queries over fixing much much bigger problems because the cto read distinct clauses were bad in some CIO magazine or something like that.
My related point is the OSS doesn't just affect the technical portion and developers. It affects business too. The CEO doesn't care if we saved them 20,000 in license fees if he has to pay an extra 100,000 replacing an OSS piece that stops getting supported. The CTO doesn't care if knockout still is great if he feels that it's already outdated 3 months after investing in it because a lot of community members jump on talking about the latest thing and stop talking about what they used to talk about.
These decisions affect business and profit and it is always a risk to go with OSS and no matter how much you explain that to the business up front if it happens guess who gets reamed for it. I would almost bet money that the person responsible for choosing to use OpenSSL at some of the major companies just lost their job or at least is getting reamed over the coals for it. They aren't going "we appreciate you wanting to support the OSS community and wanting to save us a few bucks on ssl licensing and we will just overlook the huge amount of bad press caused due to your decision".
My related point is the OSS doesn't just affect the technical portion and developers. It affects business too. The CEO doesn't care if we saved them 20,000 in license fees if he has to pay an extra 100,000 replacing an OSS piece that stops getting supported. The CTO doesn't care if knockout still is great if he feels that it's already outdated 3 months after investing in it because a lot of community members jump on talking about the latest thing and stop talking about what they used to talk about.
These decisions affect business and profit and it is always a risk to go with OSS and no matter how much you explain that to the business up front if it happens guess who gets reamed for it. I would almost bet money that the person responsible for choosing to use OpenSSL at some of the major companies just lost their job or at least is getting reamed over the coals for it. They aren't going "we appreciate you wanting to support the OSS community and wanting to save us a few bucks on ssl licensing and we will just overlook the huge amount of bad press caused due to your decision".
@Jeremy, that is exactly why in large organizations I don't recommend open source frameworks. You tell the business that we will save some money here but if it just stops being supported you have to spend dollars on having your devs contribute to it and we have no idea what kind of cost that will amount to. Or you have to spend dollars on devs contributing to it in order to ensure it's continued support. We know your not a framework company but you have to participate as one and hire framework level talent in order to help further this open source intiative. Being laughed at then kicked out follows.
Interesting article - one difficulty I have with MS open-source projects is that they're very variable as to how like a 'real' open-source project they are.
I'm thinking of a 'real' open-source project as one which holds a large proportion of discussion in public, openly debates future directions and publicly reviews contributed code - maybe something like Subversion was in its heyday.
Most of the MS 'open-source' is not much like this - it's much more a 'cathedral with big windows' than a 'bazaar'. There's lots of up-side to that, but you can see why it might be a turn-off to people looking for more open projects.
I'm sure however well-intentioned MS people are, when the majority of the project-related discussion is going on in the staff cafeteria at MS, then people outside MS are always going to be second-rate contributors.
Projects like Katana say things in their notes like "Note that all code submissions will be rigorously reviewed and tested by the Katana team, and only those that meet an extremely high bar for both quality and design/roadmap appropriateness will be merged into the source."
But there's no (future) roadmap to speak of when you follow the link, and the existing source code does not really seem to have been subject to these rigorously high standards, so the whole thing ends up (inadvertently, I'm sure) sounding more like "why you're not going to be able to contribute" than "how to contribute".
I think strong OSS projects should have:
* A limited number of obvious places where developer discussion is going on
* An obvious list of things which need contribution
* Ideally, published coding/review standards
I'm thinking of a 'real' open-source project as one which holds a large proportion of discussion in public, openly debates future directions and publicly reviews contributed code - maybe something like Subversion was in its heyday.
Most of the MS 'open-source' is not much like this - it's much more a 'cathedral with big windows' than a 'bazaar'. There's lots of up-side to that, but you can see why it might be a turn-off to people looking for more open projects.
I'm sure however well-intentioned MS people are, when the majority of the project-related discussion is going on in the staff cafeteria at MS, then people outside MS are always going to be second-rate contributors.
Projects like Katana say things in their notes like "Note that all code submissions will be rigorously reviewed and tested by the Katana team, and only those that meet an extremely high bar for both quality and design/roadmap appropriateness will be merged into the source."
But there's no (future) roadmap to speak of when you follow the link, and the existing source code does not really seem to have been subject to these rigorously high standards, so the whole thing ends up (inadvertently, I'm sure) sounding more like "why you're not going to be able to contribute" than "how to contribute".
I think strong OSS projects should have:
* A limited number of obvious places where developer discussion is going on
* An obvious list of things which need contribution
* Ideally, published coding/review standards
@Flogmeifyouwill,
Large corporations themselves generally have the money and the prestige that should be attracting that higher caliber talent. In reality those larger corporations that do not hold onto a more rigorous standard of their developers will quickly find themselves getting surpassed by their competitors. They will thus see the good talent they do have eventually moving on to greener pastures. They will then have to fill those vacancies with a higher volume of less experienced staff. This is why I have to disagree with your stance regarding OSS projects and large corporations.
Some of the best libraries out there come out of need to have something that is more pluggable into a real world application; not some theoretical idea of one from academia. These large organizations that are building industry changing services cannot always rely on out of the box toolsets, thus the benefit of having more skilled developers on staff. This skilled workforce will only drive higher quality out of the remainder of your staff. Also, since this higher skilled staff is also plugged into the community they will know and understand new technology quicker then someone who is not plugged in.
Having worked with @JeremyDMiller and the rest of the Fubu team I have seen first hand how they have helped junior developers really step up their game faster then at other jobs where I've worked. I've seen the quality of internal code improve, which in turn drives better libraries and frameworks.
Large corporations themselves generally have the money and the prestige that should be attracting that higher caliber talent. In reality those larger corporations that do not hold onto a more rigorous standard of their developers will quickly find themselves getting surpassed by their competitors. They will thus see the good talent they do have eventually moving on to greener pastures. They will then have to fill those vacancies with a higher volume of less experienced staff. This is why I have to disagree with your stance regarding OSS projects and large corporations.
Some of the best libraries out there come out of need to have something that is more pluggable into a real world application; not some theoretical idea of one from academia. These large organizations that are building industry changing services cannot always rely on out of the box toolsets, thus the benefit of having more skilled developers on staff. This skilled workforce will only drive higher quality out of the remainder of your staff. Also, since this higher skilled staff is also plugged into the community they will know and understand new technology quicker then someone who is not plugged in.
Having worked with @JeremyDMiller and the rest of the Fubu team I have seen first hand how they have helped junior developers really step up their game faster then at other jobs where I've worked. I've seen the quality of internal code improve, which in turn drives better libraries and frameworks.
How would you feel if bridges, power plants, and electric grids were designed and built by self-selected, self-organized volunteers in their free time? The way most OSS projects actually work is simply inadequate for critical infrastructure. Even worse, many of their touted benefits are out-and-out fraudulent. I have to wonder (1) how many people have made the case that "it's open; anybody can review it"; and (2) how many people have actually reviewed it? What's the ratio? 1,000:1? Of all the parties affected by Heartbleed, how many do you think reviewed OpenSSL's totally open code? I'm thinking approximately zero. The most anybody did was post some questions on a forum where somebody else, who didn't review it either, gave it the thumbs-up.
I'm glad we don't have people claiming that a suspension bridge design must be good because anybody can find flaws in it, but nobody actually tried to.
The question we should be talking about is: "How does software become an actual engineering discipline?"
I'm glad we don't have people claiming that a suspension bridge design must be good because anybody can find flaws in it, but nobody actually tried to.
The question we should be talking about is: "How does software become an actual engineering discipline?"
@John Cronan: First of all, I agree with your last point - we absolutely should be pushing to make software development a real engineering discipline. Not an art, not a craft, but an honest to goodness discipline.
However, I don't agree with your initial argument. Privately built(or state sponsored) bridges, power plants and electric grids have problems *all the time*, not least because they tend to be built and maintained by the lowest bidder. But, physics is not closed-source, so anyone is free to discover exactly how bridges are built, to discover flaws in existing methods, and to suggest improvement. And everyone is also free to ignore them, and continue using "proprietary" bridge technology.
In reality, everything anyone every built for money, for free, or for fun has inherent problems, defects and tradeoffs which get released into the wild. Therefore the illusion that because someone was paid a barrel full of cash to write a piece of software it somehow must be better and must have been thoroughly reviewed and tested is just as false as the illusion that all open source software is exceptionally well written or quality assured.
In the context of Heartbleed, the key point is that, at any point, anyone *could* have reviewed it and, in fact, someone recently *did* review it, which is why we are talking about this issue right now. If this was a closed source SSL library, we might very well never have known about it. In that respect, I place the "blame" for Heartbleed on those organisations that used it without reviewing it themselves; they could have (and should have) avoided this entirely. But I'd also blame them if they had spent billions of dollars on closed source SSL implementations as well, without insisting on having the same oversight.
I don't think though that anyone here is saying that open source is a free ride to unicorn-and-rainbows-ville; if you choose to use Open Source Software as part of critical infrastructure it 100% behooves you, the consumer, to review it and make certain that it's fit for purpose before you commit to it.
Personally I feel that it is better to be able to make a business decision like this (see the code, review the code, fix the bugs, write the missing unit tests, use it, improve it, give it back in better shape than you got it.) rather than blameability (you sold this to us, it is fail, we're gonna sue for damages and our customers will still not be able to use it because you won't be able to afford to fix it by the time we're done with you)
But that's just me :)
However, I don't agree with your initial argument. Privately built(or state sponsored) bridges, power plants and electric grids have problems *all the time*, not least because they tend to be built and maintained by the lowest bidder. But, physics is not closed-source, so anyone is free to discover exactly how bridges are built, to discover flaws in existing methods, and to suggest improvement. And everyone is also free to ignore them, and continue using "proprietary" bridge technology.
In reality, everything anyone every built for money, for free, or for fun has inherent problems, defects and tradeoffs which get released into the wild. Therefore the illusion that because someone was paid a barrel full of cash to write a piece of software it somehow must be better and must have been thoroughly reviewed and tested is just as false as the illusion that all open source software is exceptionally well written or quality assured.
In the context of Heartbleed, the key point is that, at any point, anyone *could* have reviewed it and, in fact, someone recently *did* review it, which is why we are talking about this issue right now. If this was a closed source SSL library, we might very well never have known about it. In that respect, I place the "blame" for Heartbleed on those organisations that used it without reviewing it themselves; they could have (and should have) avoided this entirely. But I'd also blame them if they had spent billions of dollars on closed source SSL implementations as well, without insisting on having the same oversight.
I don't think though that anyone here is saying that open source is a free ride to unicorn-and-rainbows-ville; if you choose to use Open Source Software as part of critical infrastructure it 100% behooves you, the consumer, to review it and make certain that it's fit for purpose before you commit to it.
Personally I feel that it is better to be able to make a business decision like this (see the code, review the code, fix the bugs, write the missing unit tests, use it, improve it, give it back in better shape than you got it.) rather than blameability (you sold this to us, it is fail, we're gonna sue for damages and our customers will still not be able to use it because you won't be able to afford to fix it by the time we're done with you)
But that's just me :)
The elephant in the room, so to speak, with the open source .net community is the lack of an open source runtime with a permissive license. There is Mono, but its open source LGPL license is mostly not applicable in today's mobile-first walled-garden app-store world. People like to use the same language on the server side as on the client side (thus, Node's popularity), so the fact that a permissively licensed open source .net runtime does not exist is a real problem.
Also, I can tell you from experience in both enterprise software development and open source development, that this perception of vendor lock-in on both the Microsoft side and the Xamarin side is causing a real headache in terms of corporate buy-in. They don't want to tie themselves to an expensive license on either side (an MSDN subscription on the MS side, or a $1000 per dev per year per OS license on the Xamarin side). They might still pay that license, if it provides value, but more and more they're either going to the web or doing the polyglot thing (Objective C on iOS, java on android, maybe C# on windows if at all).
Scott, I think the best thing you could push for going open source at Microsoft is the .Net Runtime. I really think that would stem some of the tide of developers, open source and enterprise, migrating away from .net into more free/open platforms like the web, node, rails, etc...
Also, I can tell you from experience in both enterprise software development and open source development, that this perception of vendor lock-in on both the Microsoft side and the Xamarin side is causing a real headache in terms of corporate buy-in. They don't want to tie themselves to an expensive license on either side (an MSDN subscription on the MS side, or a $1000 per dev per year per OS license on the Xamarin side). They might still pay that license, if it provides value, but more and more they're either going to the web or doing the polyglot thing (Objective C on iOS, java on android, maybe C# on windows if at all).
Scott, I think the best thing you could push for going open source at Microsoft is the .Net Runtime. I really think that would stem some of the tide of developers, open source and enterprise, migrating away from .net into more free/open platforms like the web, node, rails, etc...
Open source .NET will remain a scary proposition. The NIH is so strong at Microsoft; if anything picks up enough steam it will suddenly have an official re-implementation that has great tooling and long-term support (typically garbage at first, then deprecated almost immediately after stabilizing).
It will be interesting to see how existing open source communities are treated now that Microsoft is starting to 'move in the right direction'. What happens when the goals of the MS marketing department don't line up with an open source developer's roadmap?
It will be interesting to see how existing open source communities are treated now that Microsoft is starting to 'move in the right direction'. What happens when the goals of the MS marketing department don't line up with an open source developer's roadmap?
@Vernon, @Matt thank you for your comments. It's impressive if one can really write C# code in SublimeText today and be as productive as with Visual Studio, but is Mono really a drop-in replacement for MS .NET CLR? Does Microsoft contribute to the project?
From what I've read Mono still isn't a first-class citizen in the .NET world.
From what I've read Mono still isn't a first-class citizen in the .NET world.
I personally think open source is, for most part, rubbish! It's fine for pet projects but definitely not suitable for an enterprise environment.
Quite a lot of the open source libraries we've reviewed have poorly written code and a real lack of optimisation. Of course, this isn't the fault of those who have put effort or hard work into it but developers are lazy when it comes to testing and code reviews but that's how developers are.
Quite a lot of the open source libraries we've reviewed have poorly written code and a real lack of optimisation. Of course, this isn't the fault of those who have put effort or hard work into it but developers are lazy when it comes to testing and code reviews but that's how developers are.
Another issue with open source is, most people who are contributing only have a limited amount of time, and it's up to them on how to spend that time.
When a new open source project appears, they quickly tend to drop the current one in favour of a new one. I've seen this happen on many occasions.
This isn't the fault of the volunteer at all as they have the right to choose what they do but the point is no one can guarantee how long that open source project will last or the state in which it has been left in.
There are many issues with using open source projects in the enterprise and I've only mentioned a few above but the enterprises where I provide consultancy to have banned open source software after learning the hard way.
When a new open source project appears, they quickly tend to drop the current one in favour of a new one. I've seen this happen on many occasions.
This isn't the fault of the volunteer at all as they have the right to choose what they do but the point is no one can guarantee how long that open source project will last or the state in which it has been left in.
There are many issues with using open source projects in the enterprise and I've only mentioned a few above but the enterprises where I provide consultancy to have banned open source software after learning the hard way.
@MK: open source software excels in some domains, like web servers, database servers, operating systems and the like. It doesn't provide as much value in, say, charting libraries, UI widgets or mobile components. But to ban OSS org-wide is not only silly (equivalent to banning any other type of license, like SAAS) but impossible. Surely even the most Windows-centric org uses JQuery!
"Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author."
At first it sounds like someone else is telling about Scott; but then "that person" says "I am..." - assuming it's Scott in both cases, the perspective (probably the wrong terminology) is inconsistent.
It should either say, "I am a former..." OR "...He is a failed..."
At first it sounds like someone else is telling about Scott; but then "that person" says "I am..." - assuming it's Scott in both cases, the perspective (probably the wrong terminology) is inconsistent.
It should either say, "I am a former..." OR "...He is a failed..."
To use or not to use OSS? Well, it all depends. I dont think that there is categorical right or wrong. The choice depends many factors including the project scope, client, budget, available resources, expected project longevity and risk-profile.
Sometimes OSS is the better choice, sometimes not. And the is a big attraction with FREE.
Sometimes OSS is the better choice, sometimes not. And the is a big attraction with FREE.
Comments are closed.