Published:

OSS Strategy

Contributing shapes the ecosystem instead of only consuming it

Open Source Software (OSS) is today a major driver of technological innovation. A professional OSS strategy uses this ecosystem not merely as a consumer, but participates actively in shaping it. This secures influence over roadmaps, increases security, and strengthens the employer brand.

Innovation through openness means solving commodity problems together with the global community, freeing up in-house resources for the actual business value.

Anti-Patterns: The Passive Consumer Role

  • The Fork Trap: An open-source project is modified locally for internal purposes without contributing the changes back (Upstream). The result: upstream updates become costly and conflict-prone, as the local changes must be re-integrated with each rebase.
  • Strategic Blindness: Relying on an important library and realising too late that its development has been discontinued or is moving in an unfavorable direction.
  • Fear of Reputation: Companies are afraid to publish code out of concern that it might not be good enough.

The Strategic Contribution

  1. Upstream First: Every improvement to an OSS component in use is offered primarily to the original project. This minimises in-house maintenance costs.
  2. OSS Readiness: Establishing processes that allow developers to contribute to open source projects in a legally sound and straightforward way (see OSPO).
  3. Sponsorship: Targeted financial support for critical open-source projects on which the organisation's own infrastructure depends.
  4. Own Projects as Standard: Publishing internal tools as open source to make them the industry standard and receive external feedback.
  5. Community Management: Active dialogue with the developers and users of the projects that matter to the organisation.

The Advantage: Innovation Speed

By using and contributing to OSS, the organisation benefits from the innovations of thousands of developers worldwide, a pace no internal IT department can match on its own.

FAQ

Don't we lose our competitive advantage by sharing our code?

Only if genuinely confidential elements are shared. Most innovations arise in infrastructure, frameworks, or tooling. Which parts are safe to share should be clarified through an IP, security, and business-model review.

How do we find time for Open Source contributions alongside project work?

We treat contributions to the projects we use as part of regular maintenance work. A Bugfix in the original project is more sustainable than a local Workaround.

References