This post is an attempt to summarize the “Introduction to Innersource” white-paper written by Github in 2018. The original source article can be found here.
I’m doing this exercise for two reasons:
- Writing article summaries requires a solid understanding of the source material. I wanted that solid understanding.
- The article was long, and I wanted an easier-to-digest version to help bring this knowledge to a wider audience that may not have time to dedicate to an entire white-paper.
All credit goes to Github!
Anyone can use and help build open source software open source software. They can also view, modify, and distribute a project for any purpose—as enforced by open source licenses.
OS projects can accept changes from anybody in the world. More people = more eyes to find bugs, push features, and refactor code. More people also means more brainpower to think of new ideas and improvements.
OS projects power the web. They are discoverable and re-useable for almost any project. They can kick-start a project and reduce time to MVP.
OS Decisions are documented by default in the form of issues and pull requests. Because each conversation has its own URL and a history of comments for context, time zones matter less, and developers can work asynchronously without skipping a beat.
The best OS project maintainers create a community culture that welcomes and encourages participation. In return for contributions, they offer a chance to improve skills, find a mentor, or build a reputation.
Successful OS projects employ a smaller trusted council of primary maintainers. This speeds up decision making and ensures a responsible party always exists.
- Reduces silos and simplifies collaboration throughout the entire organization
- Typically results in better documentation because everything must be written down in issues and pull requests instead of Slack or in-office conversations.
- Makes it easy to find and reuse code on a broad scale, avoiding wasted resources and duplication
- Drives rapid development, regardless of company size
- Increases clarity between engineers and management, as well as anyone else who’s interested
- Creates a culture of openness, a precursor to open source participation
- Reinforces the pride, growth, and job satisfaction felt by team members who help wherever there is a need
The old way Orgs typically sort devs into teams (read:silos) like plats, feature teams, frontend etc. This can hurt knowledge sharing. For example, platforms teams missing out on contributions from SMEs on a feature team.
A new way Create two groups for projects / functions:
Developers, product managers, and other key decision makers within your company who are responsible for driving a project’s vision and for managing day-to-day contributions.
Developers, data scientists, product managers, marketers, and other roles within your company that help drive software forward. Contributors are not necessarily part of the direct project team but help build software by contributing code, submitting bug fixes, and more.
- Primary communication channel
- Bring up topics like bugs, feature ideas, and RFCs
- Encourage discussion through commenting
- Easily linkable to other issues and pull requests
- Provide trackable history of conversation and decision makeing
- Learn more about issues.
- Master github issues
- Living conversations about code changes
- Use draft PRs as PoCs for future change sets.
- Learn more about pull requests.
- Guide to better PRs
- Slack / teams / AOL IM (lol) etc.
- Use sparingly to avoid internalizing knowledge / decision making to only those included in the chat
- Limit use only to solve time-sensitive issues
Your company may or may not be a great fit. Consider the following questions and organizational factors
Ask these Questions:
- Does our organization have an open and transparent culture?
- Do we develop software on a single, open platform?
- Are our engineering initiatives well resourced and supported by leadership teams?
- Do developers at our organization have enough autonomy to contribute to projects outside their immediate teams?
- Does our company participate in the open source community?
- Does our engineering team use continuous integration tools?
- Are there pre-existing, cross-functional communities that work across teams at our company?
- If yes, do these communities have built-in leadership?
Consider these Org Factors:
- Your company has a vision for your projects that is both realistic and shared across teams.
- Your projects have clearly defined problems and opportunities to be addressed.
- Key participants (initiators, catalysts, evangelists) in projects you plan to innersource have experience working collaboratively.
- You have a plan to onboard and acclimate new “contributors” and other participants into your process.
- Your team has the tools and processes to communicate openly and build consistently.
- You’re able to start with an intra-organizational group of people with defined shared goals.
If you’re answering “yes” to many of these, you may be ready to start an innersource program at your company:
An effective innersource process should be informal, mentored, self-selecting, and supportive of its participants.
Kick off your innersource journey by starting small.
Use a pilot project. In this pilot, experiment with more open processes like Issue-based discussions and democratic decision making. Open access to code. Lower barriers to entry for contributors. Above all, document everything. Retro often. Pave the working paths and block the non-working ones.
Do this for a while. Document best practices and produce a guide. Share your findings across the company and ask for adopters. Scale your methods to more groups. Continue to document, retro, and adjust.
Opening up your project to outside contribution amplifies velocity. You have more eyes on your source code and issues finding bugs, improvements, and opportunities.
Opening up your source code to wider usage within your company helps accelerate the dev speed of other teams and reduces their dependence on vendor code that can lock them in.
Opening up your projects brings a new level of transparency to your organization. Not only is the code visible but also the process and decision-making behind it. Well-documented conversations help developers on distributed teams get up to speed and start building. And with work happening in the open, collaboration can also include product managers, designers, security teams, and more.
Within an enterprise, individual developers can pursue their interests, share ideas on a level playing field, and more easily learn from their peers. However, innersource also requires a cultural shift. Your team’s culture will need to encourage knowledge sharing and welcome contributions from across your organization.