Key aspects when inner-sourcing your infrastructure

Not everything in inner source is about community building [but a big portion!] and the infrastructure is basic to foster collaboration, transparency and community building.

This post is about aspects to have in mind when deploying the tooling needed to provide support to developers within the organization and across business units.

There is a more extended version of this infrastructure topic in the work-in-progress book about inner source: Managing Inner Source Projects that we, in Bitergia, are writing. Specifically in the infrastructure chapter. This is available under a CC-BY-SA 4.0 license and anyone is more than welcome to propose new sections, improve the current ones and collaborate in any way. Please feel free to redistribute!

There are two great books that already deal with the notion of infrastructure but with a focus on open source projects:

• The Art of Community by Jono Bacon
• Producing Open Source Software by Karl Fogel

This post builds on top of those giants and brings other aspects interesting when inner-sourcing.

Those aspects can be summarized in the following ones:

• Openness: as anyone within the organization have access to any piece of information, from documentation to the source code.
• Transparency: as this helps to know the author of any of the piece of source code, emails and other contributions made by any developer.
• Archivable: this helps to point to previous discussions or meetings where decisions were made.
• Searchable: this can be seen as discoverability of inner-sourced projects and information sources.
• Data Retrieval Friendly: it is basic to understand where our inner source process is right now and how this process is from the goals within the organization. Having easy-to-mine data sources help with this task.
• Access Rights: as in open source, allow to read to anyone in the organization but only a subset of those will have the rights to write.

With this 6 key aspects we can define a proper infrastructure for an inner source project. And the interesting point is that you can compare your own infrastructure and check if this fits those aspects. If not, the inner source project may force to have extra tooling for its deployment.

Let us have an example of the versioning system. Open source projects typically use Git or others such as Mercurial. However in an organization other tooling could be available. With this in mind, if we want to know if our versioning system complies with the key aspects when inner-sourcing, we can try to answer the following basic questions:

• Openness: Is my versioning system accessible by anyone within the organization?
  • Anyone can access, read, download the source code and any other contribution such as documentation
• Transparency: Is my versioning system providing actual information and autorship about any of the changes registered?
• Archivable: Can I look and then point for previous changes in my versioning system?
• Searchable: Can I look for specific changes in the source code?
• Monitoring: Is it possible to mine the versioning system?
• Access Rights: Are there several rights level to access the versioning system?

So if we have a positive answer in any of the key aspects, we can say that our versioning system is ready for inner source within the organization.

Now let us go for the rest of the development infrastructure. We have to consider other tools such as ticketing system, code review, CI, wiki/documentation, TODO, collaborative notes. We still need to have a positive answer for any of the previous key aspects. So basically we can compare how inner-sourced our infrastructure is in the following table:

Having the right infrastructure will help to bring awareness and trustiness within your incipient inner source community. Does your infrastructure follow with these aspects? Are there others to have in mind?