Monday, May 21, 2007
Sometimes it's just better to let go
Contrary to what many people think open source applications are not created by a bunch of crazy, willing to work for free volunteers. At least not only by them. Read Linus's biography to find out more. Often open source contributors are engineers employed by big and small corporations.
There are many reasons why a for-profit corporation might consider sponsoring or developing open source projects. Ensuring support for a project that is outside of company's core strategic interest and assuring the customers that they are not vendor-locked are the most commonly cited ones. Another reason - probably not so often discussed - is cooperation with your business partners.
Software companies often engage in shared deals, shared developement, strategic partnerships. It's a not-so-well kept secret that deals like that often fail, generating little more than several widely discussed press releases. It's usually the clash between corporate cultures and internal politics that prevent even reasonable deal to go forward.
The situation changes when companies cooperate within the realms of on an open source project. Especially, if it is a well established project with wide community of users and developers. First of all the rules of cooperation are commonly understood, established and transparent. The roles of sponsors, contributors, reviewers, project coordinators are well defined. It's really no that different from having a standard API interface - only these times it gets applied to people and processes not to software components.
Simple things that can take ages to establish like 'how I can get your source code' and 'what format is your documentation' are already resolved.
The biggest improvement though is in the area of day to day communication. Engineers and product managers are forced to discuss their ideas openly to get them implemented. The usual management structures that in closed source world lead to exchanges like 'tell your boss to talk to my boss before talking to me' expose their absurdity under the open source light.
No side of the deal is afraid that the other side is going to steal IP. Reciprocate licenses eliminate the false temptation of competive advantage that can be allegedly achieved by stonewalling.
This is what big bosses like best: you reduce your risk by outsourcing your communication and product management to someone who just does it better than yourself. In this case it's an open source community.
There are many reasons why a for-profit corporation might consider sponsoring or developing open source projects. Ensuring support for a project that is outside of company's core strategic interest and assuring the customers that they are not vendor-locked are the most commonly cited ones. Another reason - probably not so often discussed - is cooperation with your business partners.
Software companies often engage in shared deals, shared developement, strategic partnerships. It's a not-so-well kept secret that deals like that often fail, generating little more than several widely discussed press releases. It's usually the clash between corporate cultures and internal politics that prevent even reasonable deal to go forward.
The situation changes when companies cooperate within the realms of on an open source project. Especially, if it is a well established project with wide community of users and developers. First of all the rules of cooperation are commonly understood, established and transparent. The roles of sponsors, contributors, reviewers, project coordinators are well defined. It's really no that different from having a standard API interface - only these times it gets applied to people and processes not to software components.
Simple things that can take ages to establish like 'how I can get your source code' and 'what format is your documentation' are already resolved.
The biggest improvement though is in the area of day to day communication. Engineers and product managers are forced to discuss their ideas openly to get them implemented. The usual management structures that in closed source world lead to exchanges like 'tell your boss to talk to my boss before talking to me' expose their absurdity under the open source light.
No side of the deal is afraid that the other side is going to steal IP. Reciprocate licenses eliminate the false temptation of competive advantage that can be allegedly achieved by stonewalling.
This is what big bosses like best: you reduce your risk by outsourcing your communication and product management to someone who just does it better than yourself. In this case it's an open source community.
Powered by ScribeFire.
- posted by Damian @ 6:48 AM
| permalink
