Open Source is a thankless job. We do it anyway.
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.
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.
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!
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?
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.
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.
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.
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".
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.
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.
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.
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.
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 ;)
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.
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.
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.
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.
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.
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 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.
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'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!
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.
what happened to Knockout?
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
- 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 :)
"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.
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".
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
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.
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?"
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 :)
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...
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?
From what I've read Mono still isn't a first-class citizen in the .NET world.
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.
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.
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..."
Sometimes OSS is the better choice, sometimes not. And the is a big attraction with FREE.
Comments are closed.