Skip to content

Commit 628e038

Browse files
authored
Create 08-is-innersource-right.md (#481)
* Create 08-is-innersource-right.md * Update 08-is-innersource-right.md * Update 08-is-innersource-right.md * Update 08-is-innersource-right.md
1 parent b24acfb commit 628e038

1 file changed

Lines changed: 34 additions & 0 deletions

File tree

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Is InnerSource Right for My Project?
2+
3+
InnerSource is the application of open source principles to company-internal software development. Done right, it unblocks progress and eases adoption of shared services and modules. This article contains guidance and questions to ask yourself when considering adoption of an InnerSource approach to running your project.
4+
5+
## Will Contributions Come?
6+
7+
An InnerSource approach only makes sense if contributions are expected from the project's users. You can expect contributions to come if you see or anticipate noticeable amounts of energy directed at your project area by its users. Some examples:
8+
9+
- High amounts of project usage and adoption.
10+
- More feature requests than your team has time to fill.
11+
- Users doing workarounds to compensate for lack of features in your project.
12+
- Feature requests that take nearly as much time to explain as they would just to implement.
13+
- Multiple roadmap dependencies on your project.
14+
15+
## Will I Support Contributions?
16+
17+
Even with willing contributors, the code doesn't just flow in. You will need to encourage and support contributions via activities such as:
18+
19+
- Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios.
20+
- Inviting users to make the contributions that they need and following up with them to ensure that they do them.
21+
- Maintaining an [CONTRIBUTING.md](https://patterns.innersourcecommons.org/p/base-documentation#contributing.md) document that contains everything an engineer needs to know to contribute to the project.
22+
- Giving up-front guidance and direction as to how to implement a given contribution.
23+
- Being available during regular hours for any ad-hoc questions that contributors have.
24+
- Timely review of incoming pull requests.
25+
- Ongoing maintenance of submitted code (after the [warranty window](https://patterns.innersourcecommons.org/p/30-day-warranty)).
26+
27+
## Is it Company Specific?
28+
29+
InnerSource projects make sense when the project is specific to the company or gives the company a strategic business advantage.
30+
Other collaborative projects should be run as open source to increase the contribution pool and impact.
31+
32+
## Summary
33+
34+
If contributions will come **and** you will support those contributions **and** your project is company-specific, then InnerSource is right for your project.

0 commit comments

Comments
 (0)