InnerSourceCommons
[Pattern Draft] Require InnerSource before Open Source
Closes #285
I have created a first draft around this idea, even though I don't have an organization at hand that can confirm that they are using this practice. Therefore this is a draft/initial pattern.
However I hope that by sharing a draft it becomes easier to get other orgs to contribute their experience to this idea, as they don't have to start writing this pattern from scratch.
Some things that could still be done to improve the content of this pattern:
- [ ] Find organizations that have written/spoken publicly about similar concepts (likely not using the exact words used in this pattern) / contacting people at larger OSPOs might be a good way to go way to go about this
- [ ] Research if some of open source foundations have specific suggestions for organizations before those publicly launch a project as open source
- [ ] Solution section / could be extended with some specific examples like "how long a project should run as InnerSource before it can go open source" etc
- [ ] double check spelling of "open source" vs "open-source" etc
- [ ] link to other patterns e.g. in the Solution section
Appendix
From https://opensource.guide/starting-a-project:
If you’re a company or organization:
- You've talked to your legal department
- Relation to this pattern: for larger orgs with multiple legal entities, even the process of publishing the project as InnerSource might help to work out the legal challenges
- You have a marketing plan for announcing and promoting the project
- Relation to this pattern: marketing and promotion activities also have to be done by InnerSource projects, to gain adoption internally
- Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
- Relation to this pattern: this is the area that the pattern currently focuses on the most
- At least two people have administrative access to the project
- Relation to this pattern: should be a given :)
From https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779
- empathy training for employees
- management structures for open source (and InnerSource!!!)
From https://www.eclipse.org/projects/handbook/#incubation
- proven number of adopters
- Relation to this pattern: this could be one of the exit criteria to go from InnerSource to open source (i.e. once you have found X other teams adopting and/or contributing to your service, you can release your project as open source
From https://www.linuxfoundation.org/resources/open-source-guides/starting-an-open-source-project:
Questions to Ask Before Starting an Open Source Project
- Can we financially sponsor the project? Do we have an internal executive champion?
- Relation to this pattern: during the InnerSource phase of the project, finding an executive champion might be easier, given that you can prove some internal adoption and broader project value.
- Is it possible to join efforts with an existing open source project?
- Can we launch and maintain the project using the OSS model?
- What constitutes success? How do we measure it?
- Will the project be able to attract outside enterprise participation (from the start)?
- Is there enough external interest to form and grow a developer community?
From https://ben.balter.com/2015/03/08/open-source-best-practices-internal-collaboration/:
I love this quote:
To think you can breed code in captivity behind a firewall, using closed, hostile, or waterfall methodologies, and that once that code leaves the firewall, it will grow wings, is a fundamental misunderstanding of what it means to participate in the open source community.
So if you are managing to run your project as InnerSource at least for some time, you are forcing yourself to develop more open processes around your project. This will be a good preparation for releasing it as open source later.
We use badges to identify the stages of the project in this innersource journey (ready, Active, Attractive, champion) to further engage teams in this evolutionary process.
@fer-correa I assume these stages are used, no matter if a project wants to become open source eventually or not, right?
Could you define these 4 stages in a bit more detail?
Hi @fer-correa.
Thank your for your feedback on this PR so far!
Do you have time to review the inline comments as well as the comments above? I am looking to merge this PR as an initial pattern fairly shortly, as we are starting to hear about other organizations that are using similar approaches. It tends to be easier to add those orgs to a pattern, when we can point to a pattern in our repo (rather than to a pattern that only lives in a PR :))
Btw I added you as a co-author of this pattern. Hope that is fine for you? See b92c0ff
Sorry for the absence. Let's get this PR back on track... thanks for the reminder, @spier .
@fer-correa I want to merge this PR next week. Having the pattern directly as a file in the repo increases the chances of other readers discovering it.
If you have any time at all, the following would be an amazing contribution to this pattern from you:
- adding your org to the "Known Instances" section
- (optionally) Adding some description of how you use the pattern e.g. something like this would already be enough "We use badges to identify the stages of the project in its InnerSource journey (ready, active, attractive, champion) to further engage teams in this evolutionary process."
FYI this pattern will remain in stage "Initial" for now, so it will not be published to our book straight away. Therefore there is more time to improve this pattern even after this PR is merged.
@spier , I tried to push my changes but I don't have permission. Could you help me?
@fer-correa I cannot give you push access to a single branch only (I think). Hence I have given you WRITE to the whole repo, so that you can push your changes the easiest way possible. Will revoke those once the PR is done again.
Just to learn something here:
I think the GitHub way of doing this without extra permissions would be to fork the repo, and then send a pull request with your changes towards this branch "innersource-before-open-source". Once that new PR is merged, the commits from that PR would appear here as well. At least I think, that this is how it works :)
Or is there a even simpler way?
Thanks @fer-correa for adding Mercado Libre as a Known Instance! ❤️
I changed the text a bit to be written from the 3rd person point of view (that's how we write most of our Known Instances).
Please double check that I have not significantly changed the content.
If this is good to go just give me the thumps up here, and I will merge this PR.
Thanks for your help on this one @fer-correa! This is now live in the main branch of the repo https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-before-open-source.md
Hopefully we can improve it even further, find other orgs that are using this pattern, etc.
Then we can publish it in our patterns book/catalog as well.
Thanks for your help on this one @fer-correa! This is now live in the main branch of the repo https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-before-open-source.md
Hopefully we can improve it even further, find other orgs that are using this pattern, etc.
Then we can publish it in our patterns book/catalog as well.
I'm the one who has to thank you for the opportunity to participate and for the mentorship I received. It's always a great learning experience.
I hope to do it again by collaborating on new patterns. Thanks