Communities are one of the key driving forces behind the success of the open source business model. Without the organisations and individuals that participate, of their own free will, investing time and money, there would be no open source —or at least no successful business models on top of open source.
Simply the fact that many organisations and individuals can work together to achieve something that is bigger than the sum of its parts is quite amazing in today’s profit-driven world. Or is it? We know that an open source approach, on average, results in software that is of higher quality, more reliable and more secure than closed-source alternatives.
Clearly all parties participating in the open source world don’t do it out of the goodness of their hearts (though some do). There is a business case lurking somewhere around the corner. If we participate “here” then we can gain “there”: Simple, and sometimes very complex, investment math.
A good example of this is the hardware manufacturers who work with the Linux distribution vendors on e.g. kernel and driver development. Contributing back to the community makes a lot of sense as it enables them to sell the hardware and hardware related services to the growing Linux market. A no brainer business case.
Another example is those who develop new functions and features for open source software and contribute it back to the community so that they don’t need to maintain it (assuming the community accepts it back).
Hence, it makes sense to invest in community participation so that the maintenance cost can be reduced. In addition the chance of other people further developing your enhancements also starts to factor in.
These are a few scenarios, and if I added some more, they would most likely yield the same result: Communities are external to organisations. When you submit something to an open source community it becomes public and even if you have the IPR and copyright, you give some of that away under the license the community in question has chosen to use.
If the community concept is so powerful - why don’t we see more evidence of organisations adapting it internally? Better quality, more secure - anybody?
At the extreme, you could argue that pair-programming is the most minimalistic form of a community there is. The fact that in-house communities almost always would be much smaller than global open source communities does not diminish the potential qualitative gains, such as less bugs, smaller codebase, faster execution times and improved security.
Let’s also be clear: An in-house community is not open source - at least not by default.
Google allows its employees to spend time on their own projects and most likely there is some level of community or cross-pollination between these—kind of a Google version of a community. Beyond that, there are not too many publicly disclosed cases of internal community driven development.
Let’s face the facts: Most software organisations work in traditional silos and have rigid top-down structures. Time usage is tracked, estimated and the weekly EAC (estimate at completion) number needs to be kept up-to-date to manage variation.
It is all about being deterministic. If you have free time, then you better use it for the project because there are always bugs to be analyzed or fixed.
Communities are un-deterministic; hence by playing it safe, you can only participate in a community when the potential gain starts to diminish. It is a lot like avoiding investing in start-ups, and only putting your money into listed stocks.
Businesses need to embrace an element of risk to make communities work for them in-house. The rewards, even if unpredictable, could be promising. Putting it the other way around - can businesses afford not to try it out? The evidence is clear regarding the benefits (higher quality, more reliable, more secure) if the model succeeds.
It is not going to be simple. Source code is guarded extremely closely in some environments. And technical challenges need to be addressed such as development that requires complex tooling, version control that is not flexible enough, the use of proprietary libraries, a low level of modularity (e.g., impossible to test and run a piece of the puzzle), etc.
In fact, it is not going to happen at all unless openness is adopted at the same time. Lightweight, simple and modular architectures (that are common in open source) would not hurt either.
If in-house communities become wildly successful, what would it mean? Would open source take a hit? Even if open source relies on the community model there are also other factors at play - like the distribution model inherent in open source.
In-house communities and open source do not really compete. They are two different business models for software development that both would use the community model to maximise the quality of the final product.
Posted by Tomas Nystrom, Global Open Source Lead, Accenture