The joy of contributing to OpenStack

Contributing to OpenStack doesn’t have to be painful.

“There can be real joy in contributing to open-source projects,” said Stefano Maffulli, developer advocate at the OpenStack Foundation. “Very few companies are well-equipped to do this, and that’s when it hurts.” The main culprit? If your company is built on a foundation of making widgets and selling them to clients, that structure and process often doesn’t adapt well to open collaboration, he noted.

For example, business functions like “technology development” and “procurement” are rigid and designed for interaction with a seller-buyer relationship in mind. Product development usually uses a stage/gate approach with strict management of resources timelines, roadmaps and with open source, few of these fit.

In open source, the peer-to-peer relationship governs the entire process. Deadlines depend on social contracts instead of legal contracts; the usual leverage of enforcing agreements (firing, promoting, bonus, penalties) don’t apply, he added, speaking at the 2015 Linux Collabration Summit. The slides from his 40-minute talk are online here.

To ease these pain points, OpenStack developed free upstream training.You can sign up for the next one by May 2.

For long-term success with open source, Maffulli said change must come from within. Corporations need to change their structure and processes — break the mold for widget-making and selling, essentially — to allow for this new way of working.

For example, you can create a dedicated open-source division that operates outside the usual corporate structure. His presentation also offered other ideas for short-term solutions, including: knowing the release cycles and aligning your work with them and budgeting time to help the open source community by fixing bugs, answering questions and cleaning up documentation (“housekeeping” he called it).

gde7zqx2c9aocwtw2xhu

Teaching basic collaboration principles, including widening the conversation to the OpenStack community instead of your company’s internal water cooler, will also help. Make sure your team doesn’t have a built-in bottleneck – for example, if there’s only one person authorized to commit code on your company’s behalf. Performance objectives for individuals should take into account open source project collaboration upstream — not just for your projects. “You can’t just go into a project, contribute the feature you need and walk away from it. That’s a recipe for heartbreak.”

When asked how to best deal with compliance issues, Maffulli said the fastest way to solve them often involves circumventing the legal department. “Go straight to the CEO. If the investment in open source is strategic for your company, then you can go to legal, human resources, marketing and work things out. Not the other way around.”

If it’s not strategic for the company, prepare for a long, uphill battle that may end badly. So badly, you might want to consider looking for another job, he added. “Licensing and legal aspects are the least important part of joining an open source project,” Maffulli said. “Corporations need to change the way they develop, how they engage, and the way they think of collaboration and competition.”

Cover Photo by Thomas Hawk, article photo by Johan Carlström
// CC BY NC