Benefits of Open Sourcing Code

Posted on by

Open Source Developers @ Google Speaker Series: Ben Collins-Sussman and Brian Fitzpatrick

What’s In It for Me? How Your Company Can Benefit from Open Sourcing Code

As the open source community continues to clamor for more companies to open source their code, more and more executives are asking themselves just what open source can do for their company. There are a number of ways for a company to open source an internal project: from tossing code over the wall on the one hand to running a fully open development project on the other to any combination of the two.

This talk will discuss the costs and benefits associated with each method as well as how to successfully launch your new open source project.

I really enjoyed this tech talk about the benefits of open sourcing code. and Brian briefly summarise what motivates people working on projects to make them open source:

  • a desire to create better software,
  • or to create a relationship with you users,
  • or in some cases it’s simply good PR,
  • or perhaps it’s simply goodwill on the part of some techies,
  • or it can be a way to get free labour .
  • or it can be a way to change or subvert an entire industry ( take over the world )

They also provide a useful set of criteria with which to measure the health of an open source project, you can do this by measuring the health of the community:

  • Lots of usage ( not users! )
  • A number of active developers
  • Constant improvements and releases
  • No community == dead software

I liked their descriptions of the various differnt approaches organisations take when open sourcing software, these range from the Fake Approach, where organisations rather cynically decide to Open Source their code but do so without using a license approved by the open source initiative, this is little more than a PR exercise and in real terms means the code isn’t really open source and it can alienate both users and developers.

The second approach is to Throw Code Over The Wall, this basically means you remove any names from the code files, you add the appropriate licenses, you tar the whole thing up, post it and then simply walk away. This generates PR and is relatively effortless but it still doesn’t create a community nor does it really attract real techies. You often find that organisations that no longer wish to continue maintaining some piece of software use this approach.

Then there is the Develop Internally, Post Externally. You have a public code repository, where you develop in house but allow the external world to see what your doing. This allows occasional volunteers to submit patches but really there’s no incentive for outsiders to get involved because your not really giving anyone outside the organisation a sense of ownership … this can lead to mistrust, and creates barriers..

Next you have the Open Monarchy, where there are public discussions, there is a public repository, but committers are mostly employees and occasionally individuals outside the organisations. However in this approach one organisation or one individual rules the project and makes all the key decisions. This approach has the benefit that it will garner more credibility from the technical community and you probably will find more volunteers stepping forward to participate in the open discussions your having and to sometimes contribute. But the reality is that this is virtually the same as the previous approach except the discussions are taking place in public and as thus people can participate even though the corporate agenda always wins.

Finally there is Consensus Based Development, in which almost everything is public, all decisions are based on a consensus of the committers – project is its own organisation it exists independently of any organisation. In order to join the community you have to earn your access in other words you have to earn commit privileges. The advantage of this approach is that you build a long term, sustainable community, with a passionate following of committed developers which invariably results in better software.

I found the talk to be extremely informative and it raised my awareness or certainly made me re-think what my definition of open source actually is. In fact this is all particularly relevant to me at the moment given that our development group at Talis is beginning to Open Source some of our software, and I’m wondering what the best way of doing this might actually be.

This is an excellent video to watch and it will challenge your definition of what constitutes an Open Source project.