How does an InnerSource practice differ from that of corporate Open Source programs?

[claredillon]

InnerSource is the use of open source methods and practices to create proprietary code, and when you look at list like the OW2 open source best practices, there is significant overlap with what we are busy with in InnerSource.

However, one of the areas I've not seen discussed as often is how InnerSource practices differs from corporate open source (corporate contributions in particular).

Listed below are areas where I feel the conversations around InnerSource practices differs from that around corporate contributions to open source. Please do let me know what I might be missing, or if you have thoughts on the topic. Thanks!

What I have so far:

• Licenses - obviously different license requirements / knowledge
• Tax - Transfer pricing is a consistent topic of interest, not as relevant to open source
• Business Case - The business cases for practicing InnerSource is often quite different to that for open source contributions
• Funding - all the funding for InnerSource projects comes from with the org - very different to open source projects
• Comms - communication channels / plans can often leverage existing internal comms channels / vehicles, not so with open source.
• Security Policies - InnerSource projects may have different requirements that external open source projects (e.g. getting sign-off for InnerSource with your CISO)
• Maintenance & Technical Debt - different patterns / processes required for paying down tech debt for internal code
• Incentives & Rewards - e.g. rewards can be more readily tied to HR programs / promotions
• ROI - may be different measures of success (e.g. code re-use within org)
• Motivation - may be less about scratching your own personal itch, more about corporate dependencies

[pmalirz]

Hi @claredillon, that is a decent list I must say.

One note around "Funding". What about plenty of OS projects that are 100% under control of an org (e.g. set of the Netflix projects)?

In addition to your list, maybe if that is relevant: A sunset strategy of a project

[claredillon]

I like this @pmalirz - and you're right some open source projects are 100% funded by a corp. I was thinking more about how much of the conversations about funding OSS Projects involves many orgs/corporations coming together (like many in the LF Foundation)... so the conversation differs in that instance?

Love the idea of sunset strategy being different too.

[pmalirz]

Yes, there is a difference in this particular example.
Could we say that the "funding" in the case of InnerSource is always the same (meaning driven by a business goal), whereas in the case of OSS it can be "funded" in a variety of ways (i.e. one org, multiple orgs, no org = community)?

Another for your list might be a "Context of Change" (or maybe this is the Business Case on your list?), anyways:
Usually IS projects are driven by a specific need = a context of change.
It is very hard to think of other contexts of use beyond your particular one. When we open up a project to the wider community (OSS), we expose its code to many unknowns (that we certainly haven't considered), and the code has to grow beyond our limited view. Of course it depends on the project - unlike frameworks or UI components, small libraries don't have this problem.

[lenucksi]

On your two points of

• Licenses: All of them upon consumption remain effective. If sharing across legal entity borders happens, this might even become more interesting. Since InnerSource acts as a mulitiplicator due to the reuse of the code, special attention to the FOSS compliance parts should be taken not to worsen the situation for the projects' consumers. Of course, some of the woes&fears that usually come up upon publication are less effectfull
• Security: InnerSource projects are multiplicators. Any flaw will affect all of its users. Thus, security and quality requirements are about the same as for open source.

[fioddor]

• Deployment: InnerSource projects, at least on low maturity stages (which are the majority) tend to be designed to be deployed centrally on a single (or a reduced set of) narrowly controlled environment. Most open source projects count on not controlling where or how they will be deployed, so they need to be ready for every standard case. For open source projects, providing flexibility enhances their target user base. For InnerSource, it is less the case, and they can afford to narrow it down to corporate standards.

• Pipeline tooling: Until recently, open source projects had to rely on open source tools because of contributor scalability. Corporations can better leverage their pool of licenses of privative tooling. In the last times, open source projects are more and more falling into Microsoft's EEE (Embrace, extend & extinguish) trap by relying on GitHib actions for their pipelines.

[lenucksi]

GitLab and the various Gitea forks including Codeberg are still going strong.
However, there are quite a few people, especially newcomers to the entire tech domain, who see GitHub and Git as identical.

It is thus our obligation to highlight that this is a) not the case b) InnerSource is a direct Open Source derivative and a connection needs to remain for it to provide value and c) invest work to keep some clarity and rigidity in our concepts of InnerSource to not fall into Agilé arbitrariness and irrelevance.

[claredillon]

Thanks for these additions. @lenucksi - Can we get more of your thoughts about (b)?

InnerSource is indeed a reflection of open source practices. If we say a connection needs to remain between open source and InnerSource for it to provide value - what does that mean?

[fioddor]

I found another one:

Security vulnerability control benefits a lot from access to the source code.

Open source projects cannot afford to rely on closed-source pieces, so they can actually scan and inspect the whole source code (their own and that of their dependencies).

But it is, in fact, usual to find InnerSource software relying on privative pieces. This forces the security teams to use the usual indirect techniques to gain trust over their closed-source dependencies, like enforcing legal warranties, and conducting regular and ad-hoc pen tests, etc.

[claredillon]

@fioddor - could we include this as a specific way security practices can differ?

[fioddor]

It's beyond security policies but belongs under security practices, yes.
Security policies (security requirements) ought to be the same. But since some practices are not feasible (no access to source code) the practices for meeting the (same) requirements differ.

[lenucksi]

This is indeed a separate subject. A very much required and often neglected subject as a cursory glance over an average news portal repeatedly and without fail will show at every attempt. [...]

Approaches towards handling "binary blobs" (which is the name of what you are referring to in the FOSS domain) are also present in the FOSS domain for a long time.
Good examples of the up and downsides are e.g. the Nvidia driver and its integration/handling in Linux distributions. Another field is of course everything around the embedded device realm, from cars to IoT/"smart" devices to routers and of course smartphones and their after market firmwares.

[Silona]

I would also add governance. They don't often have elected Technical Steering Committees or Advisory Groups. Instead things often follow the corporate hierarchies esp in regards to feature development and prioritization.

Also the Contributor Code Review model may have additional steps. And there may be set orchestration tooling and processes required. Security plays a role but also scalability, and production quality as well.