I want to talk about a project that took a year and a half to get to full speed, now bringing an incredible amount of value to one of my clients: an Inner Source project.
Before discussing the actual steps required to get started, get comfortable with the definition of Inner Source:
Open source development practices brought within the corporate boundaries
No, I am not going to quote Wikipedia for once - just look at how messed-up the Inner Source page is! And no, I am not referring to the content…
So, open source practices within an organisation. The first question to ask is “why?”
How to get started
Before you write a line of code you need to start drumming-up interest for your project, which is where you will start assembling contributor teams and external members who provide extra value on top of the core maintainer team. Even users count!
Then let’s address the elephant in the room - why should someone contribute? How are you planning to make it work? Define the vision. Keep goals simple. All you need is removing silos and facilitating communication, after all. I cannot emphasise it enough: without a transparent way for people to see everything and have access to everything Inner Source won’t work.
No matter the age of the codebase you need to setup some simple ground rules: how to submit ideas, contribute, review. Make sure roles are loosely defined (e.g.: maintainer team, external contributor, etc.), followed by a definition of the process to follow. It’s not about the details as much as the perceived level of overhead - the lesser the better.
If you have at least one clear set of contributors and a core team you are ready to start.
The reasons behind an Inner Source model
Whoever proposes to use Inner Source, they need to clearly explain the reasons why they want to use it. It’s not as simple as publishing code somewhere and let users fork the repository. Doing that means dumping code in a skip.
Inner Source at its core is a variation of Open source, adapted to the world of corporate (i.e. internal) software development. The mechanisms do not change, however the conceptual pillars require a degree of change for any corporate culture.
In theory anyone can make changes, fork, adapt and enhance the codebase - it’s open by default. You build it (literally!), you run it. It’s not a process governed by change management, unless you want it to be, however losing its original meaning.
So why Inner Source? It’s usually down to two reasons: speed or quality.
With Inner Source, speed is a well-known quantity. You merge a change, it becomes available to any user. Decision-making happens at the speed of a Pull Request and it allows for an easier, faster cadence of updates.
More often than not though, the main reason is quality. Given a codebase, Inner Source raises the quality bar by the virtue of the collective review process. Code reuse means better maintainability across the organisation, as well as a leaner experience for any developer Also, it allows contributors from outside a designated core team, meaning a plurality of ideas will lead to better code.
Eventually there is also a nice side effect: clarity of relationships between development team(s) and outside actors, including non-technical stakeholders.
What’s next?
Tools. Next time though.