Inner Source : know it’s limits5th April 2019
For the last few years, along with colleagues at Red Hat, I’ve been of the belief that Inner Source (see Wikipedia definition) is a viable alternative when an enterprise organisation doesn’t want to embrace a full Open Source approach (for a variety of reasons).
The differences between Open Source and Inner Source are listed below, but the main difference is that former usually involves more that one organisation and the latter is very much internal to one.
|Open Source||Inner Source|
|Not always a formal organisation||More likely to see some form of top down formal organisation|
|Open flow of information and ideas||Some control and ownership around information flow|
|Meritocracy and Benevolent Dictatorship||Some management direction of a project|
|Social phenomenon||Induced social phenomenon|
|No budget and time constraints||Budget and time allocations needed|
|Potentially infinite number of developers||Finite resource and input|
|Consumable by all||Limited audience for consumption and participation|
|Voluntary teams||Partial voluntary, with allocations|
|Self assignment of tasks||Allocation of tasks, resource|
|Low consideration for competing tasks||Constant need to consider alternative tasks and activities|
Inner source is like Irish dancing, you are in a constrained realm. Open Source lets you fling your arms about like a Scotsman.Malcolm Herbert March 2019
There’s no doubt that having the barrier between an organisation, however large it is, and the outside world is a significant barrier to the success of inner sourcing projects. Inner source projects need constant nourishment as they are not getting nutrients from the outside world.
Red Hat’s Office of Technology in Europe does a range of consulting work around open source process and methods, helping organisations leverage the model successfully used to produce software over the last 25 years.
In the past an Inner Sourcing approach has been adopted for organisations, where either:
- there is need to keep the activity separate from the outside world
- that the project isn’t primarily software development
However, the effort of maintaining and sustaining an Inner Source environment isn’t repaid. Remove funding or support and it dies. All very Darwinian and while these extinction events also happen with Open Source projects they aren’t so dependent on internal or commercial factors.
Inner Sourcing approaches always run the greater risk of duplicating the efforts in another organisation (and the same mistakes) if the work is made widely available. So what’s the downside to Open Source and letting your team collaborate outside the corporate structure ? Being Open Source potentially needs a governance structure that cover what people can and can’t do and understanding of how it works in order to draw these guidelines up (it might be why you were looking at Inner Source initially). There are lots of sample Governance structures out there and some good articles.
Persuading an organisation to look beyond it’s own boundaries is getting easier as the recognition of the success of open source methods and process is becoming more widely understood. Whilst the consumption of open source (both community and enterprise) is the norm, collaborating and creating with upstream community projects is becoming an option for more organisations, as developers and managers have positive experiences of working as part of open source projects. For an increasing percentage of developers it’s the only way they work.
Based on the work Red Hat has done with organisations, the benefits (obvious and otherwise) of going open source include:
- the usual coding quality benefits (many eyes etc); you have a bigger community externally
- freedom for developers to interact and be creating with other like-minded developers
- developer visibility (they like their GitHub commit stats and associated kudos)
- developers hiring and retention is easier with Open Source activity and practice in place; Inner Source is less appealing. This is becoming a key benefit now that Developers are King (see O’Grady et al)
- that many organisations don’t do all (or any) of there software development in house; using an Open Source approach does lend itself to managing multiple software suppliers (standards, ways of working).
And this last point is interesting. Some organisations, that don’t do a significant amount of software development, feel that Inner Source is the only way for them to experience the open source benefits. However, if they started running their software providers as a community then issues over lock-in, poor product etc are less likely.