Introduction
Not long ago, the software-development world offered two sharply distinct models: open source and proprietary. Open-source software benefited from its trademark openness: anyone is allowed to offer contributions, so many people do. Proprietary software, on the other hand, limits access via a closed system that prizes the privacy of its intellectual property (IP).
Suppose you're a leader at a company that has made significant investments in its proprietary software. It doesn't need to be a technology company; businesses of all shapes and sizes build and maintain their own software and other IP to enjoy a competitive edge in their industry. However, you have developed a great respect for the patterns used in open source, such as source-code visibility, project bug and feature request transparency. You also like the pull-request model that simplifies the integration of external contributions. You'd really like to bring those benefits to your development teams, but don't want to open source the company's valuable software. What you really need is a hybrid that delivers the advantages of both approaches. What you need is InnerSource.
In this module, learn how to manage a successful InnerSource program on GitHub through effective discoverability, guidance, and maintenance.
Learning objectives
In this module, you learn how to:
- Contrast user- versus organization-owned projects
- Make recommendations about the number of GitHub organizations you should have
- Create discoverable repositories
- Create robust repository READMEs
- Use issue and pull-request templates
- Build transparency into repositories
- Measure the success of InnerSource within your organization
- Distribute your InnerSource toolkit
Prerequisites
- A GitHub account
- The ability to navigate and edit files in GitHub
- Familiarity with pull requests
We recommend that you complete Introduction to GitHub before beginning this module.