How to Maximize Effectiveness of Developers Contributing to Free Software

Editor's Notes

• #2: As developer advocate of the OpenStack Foundation I spend a lot of time talking to developers as well as managers, of developers and of other functions in corporations. I've realized that they're all struggling to contribute to free software in different ways. It should be a real joy instead and here are a few thoughts on how to be more effective at contributing to an open source project.
• #3: First of all let's make it clear that collaboration is very common, it's the standard way for huge corporations as Cisco, Fujitsu, HP, IBM, Intel, Google, NEC, Oracle, Qualcomm and Samsung, among others. The report captures responses from 686 software developers and business managers They say they collaborate to develop software
• #4: Not only collaboration across corporations is already important but it's going only to increase. If this is true, then my next question is: why is it so hard for so many individual developers in these corporations to contribute to a free software project?
• #5: I have found out in my experience that collaboration is not blocked by licenses It's prevented by the organization they work in. Corporate rules and culture harm their strategies and require most of the changes for collaboration to happen.
• #6: Companies want to or have to join an open source community to build new products and serve existing or new customers. How they join such communities is crucial
• #7: In too many cases corporations are unprepared Chances are they think of “classic” product-based firm (Porter): business functions are interacting exclusively within internal channels or limited interfaces. Development or procurement is done within the firm only. This view of the firm doesn't adapt very well to open collaboration
• #8: Usual stage/gate new product cycle requires strict management of resources, timeline, roadmap... all rigidly controlled (at least in theory) With open source, none of this is true, not even in theory. Collaboration starts to fail here.
• #9: What people usually notice are people yelling on mailing lists, conflicts of all sorts and failure. Collaboration becomes a trainwreck
• #10: How does open collaboration work? The OpenStack example
• #11: OpenStack confuses many newcomers because it doesn't have a traditional management structure. Project Technical Leaders elected by developers Technical Committee also elected Board of Directors mostly elected User Committee and working groups to consult the board and the Tech Committee
• #12: Releas roadmaps are discussed among developers themselves. On calendar this is what Kilo looked like: conversations in Paris to sort out complex issues and lay down a common plan for individual programs and the integrated release, the cross-project coordination etc. Then everybody home to deliver at each milestone. Checking every week in 1-1 meetings PTL with the release manager and across the whole project.
• #13: Features and bug fixes go through similar cycles, as you would expect in any software engineering process. There is more social interaction than what is shown in the graphic but this is enough to give you an idea.
• #14: If you really want to see the details of an individual patch
• #15: Companies trying to join a project like openstack face a scale issue
• #16: And they face a velocity issue
• #17: There is a complexity issue And it doesn't matter whether you look at OpenStack as layers or
• #18: Or You look at the individual components and how they're tied together. It's complex the domain, the required expertise to make it work, the wide aspects it covers.
• #19: Joining a large, rapidly changing, complex project like OpenStack is like running with bulls.
• #20: I've been doing a lot of research in the past months to find out which companies are joining this huge party.
• #21: Everyone a piece of a large puzzle, all contributing to the whole the same way The committed are those responsible for 90% of the software, you see them in the top 20 contributors in stats. These are building distributions, appliances, large public clouds. The involved are the long tail, the vast majority, adding openstack support to existing appliances, software, building smaller public clouds or private clouds. Operators who may be working for the same companies above but have different priorities. They run clouds first and contribute to OpenStack because they have to fix operational issues for example. End Users are people building SDKs and consuming those. We know little about them still.
• #22: When the products are co-developed in an open collaboration like in OpenStack the “classic” approach fails. For example Technology and Procurement are not simply internal to the firm anymore. Collaboration touches every aspect of the firm. It became very visible during my research that the model is not valid, it generates friction. Companies using a different model have more success integrating in OpenStack.
• #23: In the development lifecycle friction is most likely to appear when specs are proposed, during their discussion, at the time of scheduling and during the development cycle. Sometimes also after they're closed and merged.
• #24: Ideally your company has adopted a paradigm where collaboration with competitors and customers is more 'natural' than Porter's classic view. One such example is the Open Innovation Paradigm, proposed by Henry Chesbrough in 2004. Or similar ones. Projects can be launched from either internal or external technology sources, and new technology can enter into the process at various stages—the outside-in portion of the model.
• #25: How to avoid spinning your wheels?
• #26: The company will have to change and move things around and adopt open source principles within the organization. Take the corporate policies, HR incentives, internal tools and processes, wrap them in plastic and move them around or consider throwing them away.
• #27: OpenStack has a predictable release cycle and deadlines for accepting code are known. Adapt your product releases to it: remember that OpenStack is huge, exceptions at this size and speed are hard to grant.
• #28: Like in any other human activity, who knows you is more important that who you know. Learn how to use tools to identify the influencers in your project, get to know them and offer them something valuable. For code contributors, the best currency is code reviews and in general being helpful. Help current core reviewers sort through code contributions and improve patches before a core reviewer looks at them. Participate in conversations, online and offline, join the governance bodies and working groups. Help the projects, earn valuable karma.
• #30: Favor asynchronous communication Even if your team is in the same timezone, expect you'll have to interact with people somewhere else
• #31: Remove bottlenecks, don't leave only one gatekeeper. Example: the companies that require all commits go through one person authorized to send code. Authorize many developers to commit early and get criticized publicly if code is not ready.
• #32: Change is hard, but harder is to suffer when corporate strategies are mis-aligned. Corporate culture and processes prevents individuals to learn themselves about OpenStack.
• #33: Strictly hierarchical organizations have the worst experiences collaborating in open source. Things for them start improving when they free up teams of developers to do their thing, introducing new teams, new reporting structure that takes openness into account. Establishing an open source program helps, at some level in the corporation (usually close to C-level and senior management).
• #34: These organizational changes may take a while so to get started: Knowing how OpenStack does things is the first step to manage expectations. Developers will learn how things are done and why. Usually this results in more happiness in your ranks, higher talent retention.
• #36: To recap.
• #39: Usual new product cycle requires strict management of resources, timeline, roadmap... all rigidly controlled (at least in theory) With open source, none of this is true, not even in theory. Collaboration starts to fail here.