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!