Open Source development model
As someone who does a lot of Open Source stuff, I find myself in an interesting position in the CodePlex Foundation mailing list. I am the one who keep talking about letting things die on the vine if they aren’t successful on their own.
I am going to try to put a lot of discussion into a single (hopefully) coherent post. Most of the points that I am going to bring up are from the point of view of an OSS project that got traction already (has multiple committers, community, outside contribution).
One of the oft repeated themes of the conversation in the CPF mailing list is that the aim is to encourage OSS adoption and contributions to OSS in businesses and corporations.
That sounds nice, but I don’t really get why.
From the business side: if a business don't want to use OSS, then it is in a competitive disadvantage compared to its competitors that do make use of it, since OSS projects tend to make great infrastructure and generate high quality base to work from. If you choose to develop things in house it is going to cost you a lot. And you are likely going to end up with an inferior quality solution.
This is not to disparage someone’s effort, but a OSS project that got traction behind it is likely to have a lot more eyes & attention on it than a one off solution. The Java side has demonstrated that quite clearly.
Even in the .Net world, I can tell you that I am aware of Fortune 50 companies making use of things like NHibernate or Castle. They can most certainly fund building a project of similar size, but it doesn’t make economic sense to do so.
From the project side, if you got enough traction, you don't generally worry about the OSS fearing businesses. It is their loss, none for the project.
It would be more accurate that the project won't feel any pain if a business decide not to use it. Remember that unlike commercial software, OSS projects don't really have an incentive to "sell" more & more.
There is the incentive to grow bigger (for ego reason, if nothing else), get more people involved, add more features, etc. But unless there is some business model behind it (and in the .NET world, there are very few projects with a business model behind them), growing the project usually mean problems for the project team.
As a simple example, Rhino Mocks mailing list has an average of 140 messages per month. I had to scale down my own involvement in the mailing list because it took too much of my time. The NHibernate Users mailing list is crazy, averaging in a thousand messages a month this year alone.
That is even assuming that I want traction for a project, which isn’t always the case. As a good example, I have a lot of stuff that I put out as one-use only solutions. Rhino Igloo is a good example of that, a WebForms MVC framework that we needed for a single project. I built it as OSS, we get contributions for it once in a while. But if it gets to be *very* active, I am going to find myself in a problem, because I don't really want to maintain it anymore.
But in general, for most projects I do want to have more contributors. In the CPF mailing list the issue of getting contributions from companies was brought up as problematic. I disagree, since I don't find that the problems that were brought up (getting corporate and legal sign up for contributing work, getting people to adopt OSS for commercial uses) has any relevance whatsoever to getting more contributors. By far, most contributions that we get for the projects I am involved at are from people making commercial use of them.
But usually, I don’t really care about adoption. I have 15 - 20 OSS projects that I have either founded or am a member of, in exactly one of them I cared about adoption (Rhino Mocks), and that was 5 years ago, mainly because I thought it would give me some credentials when I was looking for a job (and it did).
For all the rest, I am working on those because I need them to solve a problem. I get the benefit that other people are going to look at them and contribute if they feel like it, but mostly, I am working on OSS to solve a problem, the number of users in a project isn't something that I really care about.
There were three scenarios that were discussed in the mailing list that I want to address in particular.
A company would like to pay you 5 times your normal rates, but they have a “no OSS” policy, thus losing the contract.
I have to say that this scenario never happened to me. Oh, I had to talk with the business a lot of time. It is easy to show them why OSS is the safer choice.
Today, that is fairly easy. I can point out stats like this: http://www.ohloh.net/p/nhibernate and that trying to build something like NH is going to cost you in the order of 130 years and ~15 millions dollars. I can tell them that going with MS data access method is a good way to throw good money at upgrading their data access methodology every two years. I can point them to a whole host of people making good use of it.
I got lots of arguments to use. And they tend to work, quite well, in fact. I may need to talk to the lawyers, but that has generally been a pretty straightforward deal. So no, I don't lose clients because of no OSS rule.
Beside, you know what, if they are willing to pay me 5 times my normal rate, I am going to be very explicit about making my preferences made and explaining the benefits. Afterward, they are the client, if they want to may me gobs of money, I am not going to complain even if I am going to use NIH as the root namespace.
Corporate developers have a problem getting permission to use OSS projects in their product or project.
I have seen it happen a few times in the past, but it is growing rarer now. The main problem was never legal, it was the .NET culture more than anything else. The acceptance of OSS as a viable source of software had more to do with team leads and architects accepting that than any legal team putting hurdles in the path.
Oh, you still need to talk to legal before, but you are going to do that when bringing a 3rd party component anyway. (You do make sure to run any commercial legal agreements through the legal department, right? You need to know that there aren’t hooks involved there).
Corporate developers have a problem getting permission to contribute to OSS projects.
Once OSS is adopted, I never run into an issue where legal stopped the contribution of a patch. There are damn good reasons for the business to want this, after all. To that manager, I am going to say: "look, we can maintain it, or we give it to the project, they maintain/fix/debug/improve it. we get great credits and we gain a lot for work we would have done anyway"
A few final thoughts, OSS projects are a dime a dozen. In the .Net space alone there are thousands. Most of them, I have to say, aren’t really that interesting. Out of those thousands of projects, there are going to be a few that would get traction, attract additional committers, outside contributions and a community.
I think it would be safe to say that there are around fifty such projects in the .Net space. There is nothing particularly noble or important in an OSS project that requires special treatment. If it gets enough attention, it will live on. If it doesn’t, who cares (except maybe the author)?
The CodePlex Foundation, however it may end up as, is going to be dealing with the top fifty or so projects, simply because trying to reach the long tail of OSS projects is a futile task. I mentioned what I think would be good ways of helping the top projects (resources, coaching, money).
Another approach would be to turn it around, the CPF can focus on building a viable business model for OSS projects. A healthy OSS project is one that makes money for the people who contribute to it. It may be directly or indirectly, but if it isn’t going to do that, it isn’t going to live long. A labor of love would keep one or two committers working on a project, but it wouldn’t generally sustain a team.
Finally, something that I think seems to get lost in all the noise around it, Open Source projects are about the code. I hear a lot about legal issues, making business adopt OSS, etc. I don’t see discussion about the main thing.
Show me the code!
I've said it before and ill say it again...I appreciate your honesty and pragmatism. As the primary .net OSS contributor it'd been easy for you to exploit/promote CPF. Instead we get an honest appraisal...thanks.
"It is easy to show them why OSS is the safer choice."
(Me talking) OSS is safer because a wider variety of eyes see it. Bugs get fixed faster (obviously this varies project to project). Safer in terms of cost.
Just a few of mine, more will surely strike me later.
Maybe the __theme you mention would make more sense if you think of the mission of CPF as not so much "encouraging" OSS adoption, but "facilitating" it.
As you point out,
"if a business don't want to use OSS, then it is in a competitive disadvantage compared to its competitors that do make use of it".
If this is true, it would indicate businesses want to avoid being caught in that competitive disadvantage, but they may have other significant barriers to OSS adoption that are difficult to navigate. I imagine CPF wants to help navigate that gap.
However, per other discussions, I do agree this shouldn't be the sole focus of the CPF.
No need for me to upgrade MS data access routines in a long, long time. ADO.NET has been working fine forever. One of the joys of working at a lower level. I've been able to crank out projects while everyone else chases their tail every 2 years learning something new.
ADO.NET will be around for a long time.
My boss is somewhat paranoid about OSS. He thinks Oracle is going to start suing us if we use MySQL without paying them. Fortunately, he gives us a fair bit of freedom, so we use OSS libraries left and right.
I've witnessed the clash of OSS versus inhouse before. However, in our team's case, it was more of a fight based on "not built here" as opposed to legal issues. Thankfully, common sense has now prevailed.
I always say the same thing. Whose solution is going to be the best and represent the best value for money? In nearly all cases, an established OSS solution can integrated relatively painlessly. It solves the problem and costs very little in development terms.
More to the point, if it is a mature product with a lot of talented contributors (many of which will have become experts in the area), how in the hell can anyone entertain the thought that they can do it better at the first attempt? How can they maintain that it offers the best value for money for the company?
Again, you hit the nail squarely on the head.
I think the key part in using OSS is to go through the same selection process as you would using a third party closed source solution, or an in-house built solution for that matter. There's a bunch of well designed OSS projects out there (NHibernate, Castle stuff, some others I can't remember), but there's also a lot of crap (pardon my French).
From experience I know it's VERY bad to start using some component, no matter what source, which turns out to be badly designed. It only adds to frustration AND time you have to spend using it, and the nett result will usually turn out negative.
This is something I hope the Codeplex Foundation will contribute to: Guide some of the 'lesser' open source projects, so at least the quality will be high. When the quality/stability of a project is up to standards, adoption will probably be easier, which will benefit the project again.
My comment about what is happening is well resumed in this link
How do you see a new project becoming one of the top fifty?
Isn't there a chance that existing projects that get CPF support stifles anything new?
I couldn't agree more.
If they don't remove the barriers then let them fail. Isn't that just natural selection at work?
Open Source or Other way it costs money to do it! I frankly don't see any difference. No one is advocating to reinvent wheel. But to say that OSS has immense business benefits is not true, in my opinion anyways.
You said you can use Microsoft methodologies and rewrite every 2 years? That's not true, where do you get this from ? Also are you saying nHibernate will never get an upgrade that's compelling to move to newer versions ?
OSS is like paying to "select few" higher rates then market to support the application. Closed Source is supported by "masses". In the end, the cost is the same if you look at business perspective.
Look at the history:
Strongly Typed DataSets
Linq to SQL
Linq to Entities
Linq to Future ?
And I don't get the math regarding the cost being the same. Not at all.
"If they don't remove the barriers then let them fail. Isn't that just natural selection at work? "
True, but that's not for you or me to decide.