Strategy about the release internal projects (innersource) to open source

[anajsana]

The question was raised via TODO slack:

Question for folks who may have dealt with strategy and technical decisions about release an internal project (innersource) to open source: I´d like to understand what kind of appproaches to open the source code repository into public repo, considering an environment with strict security constraints. I´ve checked a lot of references about this topic, but in terms of technical solution, I notice that using organizations to separate the internal repo (inside an org) and public repo, with 2 differents orgs, may be a possibility to drive the discusstion about this subject. Feedbacks and suggestions are welcome! Thanks so much!

[anajsana]

Kevin P.Fleming Replied:

Can you describe what sort of problems or requirements you are trying to address with that solution? It's hard to provide feedback on a proposed solution without know what problems it is supposed to solve.

[anajsana]

Gil Yehuda replied

Earlier this week someone asked me if the industry had a generic process for publishing new open source projects. Part of my response: I don’t think there’s a generic process yet. When an entity decides it wants to launch a code project, they have a ton of bespoke concerns that drive their process. E.g. sometimes you publish a project because you are publishing a scholarly paper and they require the related content to be open source. That’s a publish and forget process. Alternatively you might be publishing a project that your customers will need in order to integrate with some api product you provide. In that case you want to make sure the code is well documented and you can support it. Alternatively you want to launch a project to commoditize a competitive project. So you need to focus on attracting a community. Very different outcomes and very different processes.

These considerations then apply to the repo strategy. Do you have one open source repo that you use for all (the community and internal use) or do you mirror? If you mirror, which gets your attention? Do you develop internally and the publish to the community (ignoring them?) or do you work with the community and have them help drive the project? Totally depends on your goals.

[anajsana]

Alex Scammon replied

yeah, like Kevin and Gil are suggesting, for strategy it totally depends on what the project is and what your goals are.

Danielle, as for the technical implementation, we have a complicated system of chains, gears and pulleys that drive synchronization between our internal, air-gapped, on-prem Github and the public cloud Github. Like Gil's response, there are three or four different scenarios each with their own method of syncing depending on the strategy

[anajsana]

Justin replied

the big rocks for us are trademark reviews, org sponsorship, vision/community plan, and maintainer commitment to the best of their ability.

[anajsana]

Alex replied

oddly, it’s much less that for us and much more “is any of this core IP?”

[anajsana]

Stephen Kilbane replied

I think it's easy to focus on "are we giving away our secret sauce?" or "are we revealing confidential information?" because they're natural questions for a commercial org - and you really do have to address them. But it's easy to forget that GitHub isn't a dumping ground - you shouldn't be putting something there unless you're willing to invest in the maintenance and support of that software as open source, and any community that may come to depend on it.

[anajsana]

There's a halfway-house: releasing something under an open source license, but with explicit intentions not to maintain or develop it. In such cases, it might be better to release via your own org's website rather than a community-centric location such as GitHub.

[anajsana]

Sri replied

and what license it will be released on I reckon.

[DanielleAlmeida]

Hello folks! Thanks so much for your attention here.

I m trying to cover the main concerns related to this topic, such as the decisions about sponsorship, licenses, dependencies, security, IP, trademarks, legal, project maintenance, FTE teams, roles & responsabilities, documentation, community, communication release plan, etc.
Just bring the pain points to discuss before starting the repo strategy.
There is no "one size fits all" decision. And perhaps any of the points above will be the "stop loss" conversation, before the technical implementation.