2009/04/17

Open Source is about Participation

As I have talked about earlier I am holding an education for company management about Open Source Communities. Since I can't release the slides directly I am going to blog a bit about what these slides contain.

One of the things I am trying to get across the table is that getting involved in a Open Source Community as a company is hard work and often counter-intuitive to old business practices. To illustrate this I have created some case studies about companies that have tried to involve them-self in the community and the different outcomes of that. In my examples I use Nokia, Apple, Google and Sun as examples (and some more of them), all these companies are interacting with the Open Source community in different ways. All of these companies have both succeeded and failed with their interactions (I won't comment on the individual cases in this blog post, but I am still interested in your feedback, what do you think about the companies listed above and do you have other examples of companies failing or succeeding with Open Source?).

While I was researching these different companies (most of my research was based on google searches like "opensource at X") I ran across Sun's Open Source webpage, this page states that 'Open Source is about Participation'. I think that is one of the most accurate one-liners about Open Source I have ever heard. In order to be able to accepted and successful with a Open Source Community you must show that you can participate, create code and work together with the community with it rules.

I think very few Open Source Communities would accept companies that tries to 'buy' their way into gaining influence over a certain project. But companies that can send relevant, well written patches that implements a feature or fixes a bug in a project they are using can succeed. Many nerds just care about code and that is the way it should be.

Interacting with a Open Source Community is not like interacting with business partner, few communities will implement features that they don't like just because your company needs it. Many community volunteers have a lot of pride invested in their projects and will place code-style and technical aspects before the needs of their end-users. This is very different from how a company works, because companies needs to see to the user needs before the technical aspects of the actual code (this might actually explain why most proprietary code is such a mess - "We need this now, or else!").

This means that companies have to care about things like this when they are contributing to Open Source projects, otherwise they might never get their patches merged.

So to sum up, if you want to gain the trust of a Open Source Community, participate and show them the code!

No comments: