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!

Open Source Community Eduaction

Purple Scout was contracted to do a Open Source Education a while back. The customer wanted a education that gave them the history, business and legal aspects, but they also wanted a section with some "real life" stories, from someone that have worked in a Open Source community already. While both my bosses handled the business and legal aspects I tackled the community section.

After almost a month of preparation, we held the pilot in front of a smaller group today. I was a bit nervous at the start but managed to hold a very engaging talk about the different inner workings of a community and a generalization of what drives open source hackers. It was a fun and interactive group that I managed to provoke a couple of times :-)

I would love to share the slides I did, but unfortunately they contain some information that I can't spread, therefore I will try to blog a bit about the conclusions that I managed to draw from all of this.

Also a question: What do you people think is the driving factor for participating in open source communities as a company, i.e. not for you personally, but what would drive your company to work with open source?