SAP has described an InnerSource programme run by a dedicated programme office, with published documentation and training, a portal for finding projects and a linter applied to repositories. An organisation that has already opened every internal repository and published a contribution guide asks what a programme office and a linter would add that policy did not. What is the answer, and where would copying this be a mistake?

The situation they were in

A vendor with a very large engineering population and a product portfolio assembled over decades has the conditions that make innersource attractive and the conditions that make it fail. Attractive, because the same capability is implemented repeatedly across product lines and a contribution is cheaper than a feature request. Failing, because at that size a contributor cannot find the right repository, and cannot tell whether a repository they found will accept anything.

Opening the repositories addresses neither.

What they chose

SAP's own account (open-source blog, January 2024) describes an InnerSource Program Office as the driving function, with documentation, training material and published case studies. A 2025 FOSS Backstage talk from SAP on running the programme names the tooling: a portal and a linter. Those two artefacts are the interesting part, because each attacks a specific failure that policy cannot.

The portal is a discovery mechanism. Across many thousands of repositories, "the repositories are open" is not a usable statement. A searchable index of projects that are actually accepting contributions turns an unbounded search into a short list.

The linter is a readiness check. It inspects a repository for the things a contributor needs: a README that explains what the project is for, a contribution guide, a stated review expectation, tests that run. A repository that fails it is open but not contributable. This converts "we encourage contributions" from an aspiration into a property that can be measured per repository, which is the difference between a programme and a memo.

Why it fit their constraints

At that scale the binding constraint is maintainer attention, and the second-order cost of a bad contribution is higher than the benefit of a good one. A linted repository with a published contract lets a maintainer say no in minutes rather than in a week of discussion, which is what keeps openness affordable. A programme office makes that economics somebody's job rather than a side activity of whichever director cares.

What it cost them

A standing function with no delivery output of its own - documentation, training, tooling and advocacy, funded indefinitely. That is defensible at tens of thousands of engineers and absurd at two hundred. There is also a quieter cost: a linter defines what a good repository looks like, and every rule it adds is work imposed on every repository owner, most of whom will never receive a contribution. Keep the rule set small or the readiness check becomes the new compliance burden.

What to tell the organisation in the question

Their missing pieces, in order of return:

1. A readiness signal per repository, even if it is three checks and a badge. Open is not the same as contributable, and contributors currently cannot tell the difference.
2. A findable index of what accepts contributions. Eleven contributions across 200 repositories is usually a discovery failure before it is a motivation failure.
3. A published response expectation - "we triage within three working days" - because the cost a contributor fears is not rejection, it is silence.
4. A programme office only if the estate is large enough to justify one. Below a few thousand engineers, this is one person's part-time remit plus the tooling.

When copying this is the wrong answer

Do not copy the programme office. It is the artefact of scale, and in a 300-engineer organisation it creates a function that reports on an activity that should simply be happening. Copy the linter and the index, which cost a week and work at any size.

Do not copy it at all if the constraint is capacity rather than discovery. If maintainers already receive more contributions than they can review, a portal that makes them more findable makes the problem worse. The diagnostic is cheap: look at the open contribution queue. A long queue means capacity; an empty queue across many repositories means discovery and readiness. Policy, portals and linters only help the second case - and an organisation with the first one should be funding maintainer time, not tooling.