From f3547ce87132be983176e12da145f44b98aa9972 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Fri, 5 Aug 2022 17:35:38 -0500 Subject: [PATCH 1/4] Create 08-is-innersource-right.md --- introduction/08-is-innersource-right.md | 33 +++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 introduction/08-is-innersource-right.md diff --git a/introduction/08-is-innersource-right.md b/introduction/08-is-innersource-right.md new file mode 100644 index 00000000..32a6f645 --- /dev/null +++ b/introduction/08-is-innersource-right.md @@ -0,0 +1,33 @@ +# Is InnerSource Right for My Project? + +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. + +## Will Contributions Come? + +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 space by its users. Some examples: + +- High amounts of project usage and adoption. +- More feature requests than your team has time to fill. +- Users doing workarounds to compensate for lack of features in your project. +- Feature requests that take nearly as much time to explain as they would just to implement. +- Multiple roadmap dependencies on your project. + +## Will I Support Contributions? + +Even with willing contributors, the code doesn't just flow in. You will need to encourage and support contributions via activities such as: + +- Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios. +- Inviting users to make the contributions that they need and following up with them to ensure that they do them. +- Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project. +- Giving up-front guidance and direction as to how to implement a given contribution. +- Being available during regular hours for any ad-hoc questions that contributors have. +- Timely review of incoming pull requests. +- Ongoing maintenance of submitted code (after the [warranty window](https://patterns.innersourcecommons.org/p/30-day-warranty)). + +## Is it Company Specific? + +InnerSource projects make sense when the project is specific to the company or gives the company a strategic business advantage. Other collaborative projects should be run as open source so as to increase the contribution pool and impact. + +## Summary + +If your project is company-specific *and* contributions will come **and** you will support those contributions, then InnerSource is right for your project. From 6eb4a85829bbf0a5ae798a83c091c20b8d246940 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 9 Aug 2022 11:25:44 -0500 Subject: [PATCH 2/4] Update 08-is-innersource-right.md --- introduction/08-is-innersource-right.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/introduction/08-is-innersource-right.md b/introduction/08-is-innersource-right.md index 32a6f645..e01d4585 100644 --- a/introduction/08-is-innersource-right.md +++ b/introduction/08-is-innersource-right.md @@ -26,8 +26,9 @@ Even with willing contributors, the code doesn't just flow in. You will need to ## Is it Company Specific? -InnerSource projects make sense when the project is specific to the company or gives the company a strategic business advantage. Other collaborative projects should be run as open source so as to increase the contribution pool and impact. +InnerSource projects make sense when the project is specific to the company or gives the company a strategic business advantage. +Other collaborative projects should be run as open source to increase the contribution pool and impact. ## Summary -If your project is company-specific *and* contributions will come **and** you will support those contributions, then InnerSource is right for your project. +If your project is company-specific **and** contributions will come **and** you will support those contributions, then InnerSource is right for your project. From 31c883b62d58ab0fa141441dbd94a09aabc4468b Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 9 Aug 2022 11:27:44 -0500 Subject: [PATCH 3/4] Update 08-is-innersource-right.md --- introduction/08-is-innersource-right.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/08-is-innersource-right.md b/introduction/08-is-innersource-right.md index e01d4585..b2eaadde 100644 --- a/introduction/08-is-innersource-right.md +++ b/introduction/08-is-innersource-right.md @@ -31,4 +31,4 @@ Other collaborative projects should be run as open source to increase the contri ## Summary -If your project is company-specific **and** contributions will come **and** you will support those contributions, then InnerSource is right for your project. +If contributions will come **and** you will support those contributions **and** your project is company-specific, then InnerSource is right for your project. From 767cc9dbc5e257bc8d84d0bef3bf8a4c1400e142 Mon Sep 17 00:00:00 2001 From: rrrutledge Date: Tue, 9 Aug 2022 11:30:04 -0500 Subject: [PATCH 4/4] Update 08-is-innersource-right.md --- introduction/08-is-innersource-right.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/08-is-innersource-right.md b/introduction/08-is-innersource-right.md index b2eaadde..e022a0c7 100644 --- a/introduction/08-is-innersource-right.md +++ b/introduction/08-is-innersource-right.md @@ -4,7 +4,7 @@ InnerSource is the application of open source principles to company-internal sof ## Will Contributions Come? -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 space by its users. Some examples: +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: - High amounts of project usage and adoption. - More feature requests than your team has time to fill. @@ -18,7 +18,7 @@ Even with willing contributors, the code doesn't just flow in. You will need to - Understanding users' scenarios and suggesting what contributions in your project could help them to meet those scenarios. - Inviting users to make the contributions that they need and following up with them to ensure that they do them. -- Maintaining an CONTRIBUTING.md document that contains everything an engineer needs to know to contribute to the project. +- 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. - Giving up-front guidance and direction as to how to implement a given contribution. - Being available during regular hours for any ad-hoc questions that contributors have. - Timely review of incoming pull requests.