Culture / Open Source / Contributed

Want to Start an Open Source Program Office? Here Are 6 Marks to Hit

15 Jul 2020 2:00pm, by

Bob Lord
Bob Lord is one of the world’s leading authorities on emerging technologies and open platforms to transform how businesses engage with customers. Bob is Senior Vice President, Cognitive Applications, Blockchain, and Ecosystems at IBM, where he is responsible for infusing emerging and open technologies across the business. He oversees IBM’s market-leading blockchain business and drives the company’s key partner ecosystems across developers, global systems integrators and independent software vendors, which help clients accelerate their journey to the cloud and gain competitive advantage.

Now more than ever before, enterprises should reevaluate and evolve open source strategies to maintain flexibility in today’s landscape. The code is efficient, strong, flexible, and continually updated by some of the best developers in the world. Open source provides freedom from vendor lock-in as well as supports hybrid and multicloud environments, a destination where many larger companies are heading.

Open source offers so many benefits that there’s a certain inevitability to it: if your enterprise hasn’t integrated it by now, there’s a good chance it will soon. Black Duck by Synopsys just released its annual Open Source Security and Risk Analysis (OSSRA) report, which analyzed the anonymized data of more than 1,250 commercial codebases from 2019, and found that nearly 99% of them contained open source code. Open source pops up most frequently in the marketing tech and cybersecurity sectors (78% respectively) followed by transportation (69%) and mobile apps (68%), according to OSSRA.2

But open source is about more than just code. It’s also about the planning that happens before the code is written, how that code is used and helping to foster a welcoming environment where a community can grow. That’s where an open source program office, (or OSPO, for short) comes in. An OSPO encourages, organizes, and supports the use of open source code within your company. A well-run OSPO is an enabling center, helping programmers and their teams develop standard coding and organizational practices, processes, and toolsets.

When running an OSPO, there are several marks you may want to hit, and pitfalls to avoid. I’ve come up with six.

1: Be Clear About Your Goals and Objects

You’re attracted to open source for a reason: it accelerates the speed at which developers can do their jobs and learn from others. But you also want to be precise about where, exactly, open source projects are important to your organization. Have a clear plan about where open source code will be used — it helps to start with the end in mind — and the goals you hope to achieve. You may even find assistance in crystallizing those ideas from others outside your organization; the open source community helps developers grow their knowledge through ecosystem support. Be authentic, honest, and realistic with what you hope to achieve, and then focus. There are many open source projects to choose from — for instance, if you’re moving toward a cloud native environment and adopting container technology, getting involved with the Cloud Native Computing Foundation is a great place to start.

2: Don’t Overcommit too Quickly

Start small, and build trust both externally in your open source projects, and internally with the peers in your organization.  Don’t just talk a good game — show results. And, again, reach out to community mentors if you’re struggling. There is an amazingly rich variety of resources in the open source world and you’re now a part of it. Build your OSPO effectively over time, and learn from mistakes. It’s better to laser in on a handful of strategic communities before attempting to begin with a broader open source engagement. Pick three, as a beachhead. For instance, they could be in Continuous Integration/Continuous Delivery, Artificial Intelligence, or Open Data. If you take on too much, too fast, you’ll risk burnout. Start small and build up your wins first.

3: Contribute to the Open Source Community

Every company has its own culture: how they conduct business, what’s important to them, where and how they excel. Bring that personality to the larger open source community. Find ways that your OSPO can be an active and contributing member of the open source world. For instance, take on daily community “chores” by fixing some code or improving documentation. Don’t just extract. Become a valuable contributing member, not just an open source consumer, like some companies are. Finally, remember to write and contribute code. Strive for quality but not perfection. It is the foundation of your reputation. And it never hurts to be friendly and courteous. The golden rule applies to open source.

4: Learn the Difference Between OS Licenses, and Support Open Governance

There is no single Open-Source Software (OSS) license that fits all needs. In general, there are permissive licenses, which can be easier to use and incorporate into your IT projects. Then there are more restrictive licenses, which have more specific terms and obligations that must be carefully met. This is where your legal department can help guide you.

But there is another key consideration: How is the OSS project governed? Many are run by an individual or controlled by a single vendor, and limit contributions from others. Some open source projects welcome code contributions but are closed when it comes to setting technical strategy and direction. An open governance structure will ensure that multiple entities can collaborate to the benefit of all, and keep any one person from benefitting disproportionately. This encourages the commitment of the best players. In addition, the open technology projects managed under open governance in leading OSS Foundations (such as Apache, Eclipse, Mozilla, and Linux) tend to be more successful, have a longer life, and tend to be less risky than those projects controlled by a single vendor, or are more restrictive in their governance.

5: Establish Strategic Priorities

Set achievable goals. That begins with a high-level internal consensus, driving agreement on the details of the approach and investments you’re going to make. Formalizing your organization’s commitment to open source management and strategy creates guidelines that boost efficiency and minimize risks. Obtain buy-in throughout the company and at many levels. A critical first step is to create a strategy document. This will help you maximize the open source benefits, while providing an action plan if mistakes are made, such as failing to maintain code properly. Your strategy document can get leaders excited, and it helps individuals and inventors make better decisions. This brings up the final point…

6: Establish Key Performance Indicators

Well-considered KPIs help an organization assess progress. They keep teams aligned and the enterprise productive because they are closely aligned with strategic objectives, for the entire company or an individual. In the end, KPIs keep everyone on the same page and help justify the investments you’re asking your business to make. Track your contributions to the open community, both as a general organization as well as those from individual staff members. And remember to use KPIs as a positive motivator and reward your top performers.

Open source can radically reshape industries and companies, yours among them. An OSPO is a key part of creating that successful open source implementation, and it should also be an integral part of maintaining your presence and contributions in the open source ecosystem.

Feature image via Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email:

A newsletter digest of the week’s most important stories & analyses.