Many “open source” projects are benefitting in ways more community-driven than technical or revenue-based. This is largely due to the practices enjoyed by these projects, such as transparency and inclusiveness that fosters creativity and participation from developers of differing points of view and skillsets. Meaning that anyone that needs a bug fixed or a new feature can provide a patch to the code and documentation for review and acceptance by the maintainers of the project. This can mean getting those extra needs you have in the base product faster than waiting for the regular committers to schedule the task and get to it sometime in the future.
I look at that and see no reason why an organization shouldn’t be able to have those same benefits for the code they have in-house that they are not wanting to “open source”. I have found that there is a community that is dedicated to this very concept, inner source. Inner-source is a culture and process movement to facilitate collaboration among development teams. Similar to open source, although it only pertains to private repositories within the organization. As we see open source becoming more prevalent in our industry many organizations are taking notice of the collaborative process involved. It isn’t possible for all software written to be open source for all organizations, but why should those organizations and private projects not benefit from open source concepts.
- Facilitate transparency amongst all development teams in the organization.
- Reduce the dependency issues on other teams by submitting MR’s for review to the dependent projects as needed.
- Breaking down silos
- Accelerate cross-project learning
- Improved documentation
- Process standardization
- Foster innovation
- Release passion and creativity
By promoting developers to provide code submissions for any of the repositories in the company, challenges could arise.
- Conflict with “day” job as developers may decide to spend more time on other projects than those their team owns.
- Silos may not fully break down
There is a lot that has been written on this topic including a site dedicated to the concepts, https://innersourcecommons.org/.
- https://about.gitlab.com/solutions/innersource/
- https://resources.github.com/whitepapers/introduction-to-innersource/
- http://paypal.github.io/InnerSourceCommons/assets/files/AdoptingInnerSource.pdf
- https://medium.com/swlh/inner-source-b6c9e73cb8dc
Many of the examples however target very large organizations with large global development staff. As a result, many of the writings and talks tend to focus on the processes needed to govern the inner source initiative as they would an “open source” project. I wonder though if this is needed for organizations of all sizes. Many “open source” projects begin and grow organically with an assumed policy. So why can’t there be a policy of inner source along with some standards for all projects?
From the reading and talks, it seems there are a set of basic needs a project must fulfill to facilitate inner source.
- Defined Ownership within projects
- Good Review process
- Good Documentation
- Automated testing
- Coding Standards
- Code Quality Checks
The list of needs isn’t too large and isn’t necessarily something that shouldn’t be required of all projects regardless of inner source. So it seems to me that a company could begin to benefit from inner source concepts with a small subset of the requirements (in addition to the above needs).
A policy of allowing developers to submit MR’s to other projects (especially those their products rely on).
A manner of introducing the different projects in the company to the developers.
A way to foster participation
It is possible that through the process of fostering inner source within the company there will be projects that emerge that may be of value for others. This would begin a conversation of open source based on a few questions;
- have something of value to share?
- is there a strategic decision policy in place?
- are you ready for doing open source? (capability, culture, governing, etc)
In this situation, “inner source” may be a step towards open-source by providing an opportunity to work out the overall governing policies that may be necessary for “open source”.
I would like to hear from everyone in the comments their thoughts on this topic.
Top comments (0)