Maximize Effectiveness of Developers Contributing to Free Software
•Download as ODP, PDF•
0 likes•522 views
The document discusses how corporations can maximize the effectiveness of their developers contributing to open source software. It recommends that corporations tweak their new product development and customer service processes to align with open source release cycles. Corporations also need to think outside their boundaries and allow developers more freedom to interact and contribute upstream to open source communities. Long term engagement and collaboration with open source communities can help corporations gain benefits like fixes to issues and code improvements.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Maximize Effectiveness of Developers Contributing to Free Software
Similar to Maximize Effectiveness of Developers Contributing to Free Software (20)
Recently uploaded
Recently uploaded (20)
Maximize Effectiveness of Developers Contributing to Free Software
- 1. How Corporations Can Maximize Effectiveness of Developers Contributing to Free Software Stefano Maffulli – Developer Advocate OpenStack Foundation Linux Collaboration Summit – Santa Rosa, Feb 2015
- 2. Source: Collaborative Development Trends Report – Linux Foundation, March 2014 http://www.linuxfoundation.org/publications/linux-foundation/collaborative-development-trends-report-2014
- 3. Source: Collaborative Development Trends Report – Linux Foundation, March 2014 http://www.linuxfoundation.org/publications/linux-foundation/collaborative-development-trends-report-2014
- 4. The Short Answer The software license has nothing very little to do The hard reality is that corporations have to change Tweak new product development and customer service Learn to think outside corporate boundaries Think long-term when engaging open source communities
- 5. How companies join open source communities
- 6. Classic Corporate Value Chain Inbound Logistics Operations Marketing Sales ServicesOutbound Logistics Human resources management Technology Development Procurement Firm Infrastructure M argin
- 7. “Classic” New Product Development
- 9. How OpenStack Is Made (Upstream)
- 10. The Actors involved No traditional management structure No 'dictator' No 'architect' No 'product manager' Representative democracy
- 11. The Release Process Time-based releases, every 6 months The cadence keeps people focused Milestones every 4-6 weeks to maintain the rhythm
- 12. Lifecycle of a Feature Roadmap defined via blueprints+specs Best proposed at the beginning of the cycle Must have specifications attached Code is peer-reviewed Blueprint filed Specification is proposed Specification is discussed openly Specification is approved Blueprint is scheduled for milestone Code development lifecycle Blueprint is closed
- 14. OpenStack is big Code repositories Known Companies Monthly Contributors Countries 260 600+ 139 185 2,902 Known Contributors Official Projects 22 Patches Merged for Juno 18,704Total Lines of Code +2.0M
- 15. OpenStack Moves Fast A new release every 6 months New projects being added in every release Austin San Antonio Santa Clara Boston San Francisco San Diego Portland Hong Kong Atlanta Paris Vancouver 0 1000 2000 3000 4000 5000 6000 Participation to OpenStack Summits
- 19. The OpenStack Ecosystem (Downstream)
- 21. Shared Innovation Value Chain Inbound Logistics Operations Marketing Sales ServicesOutbound Logistics Human resources management Technology Development Procurement Firm Infrastructure M argin OpenStack Collaboration
- 22. Blueprint filed Specification is proposed Specification is discussed openly Specification is approved Blueprint is scheduled for milestone Code development lifecycle Blueprint is closed Where Friction Accumulates Friction Friction Friction Friction
- 23. Collaboration in Product Development OpenStack Collaboration Effort © 2004 Henry Chesbrough Docker Node ...
- 26. Reorganize corporate release cycles with the cycles of free software Corollary: adopt predictable release cycles for your free software project
- 27. Enable all employess to get known by the relevant people
- 28. Watercooler conversations are bad
- 30. Allow multiple paths for information to flow
- 31. Things That Create Disappointing Results Team organized around internal product cycle Only few engineers allowed to contribute upstream Performances measured against internal objective Community cycles and roadblocks are not considered Individuals are not motivated to contribute IT policies block access to wiki, email, IRC, git-review Engineers are prevented to interact with community Rigid chain of control for publishing code Individual engineers cannot commit code without supervisor's approval Makes patches grow very big before they can be pushed
- 32. Freeing Resources For Collaboration Open Source Program
- 33. Too Much To Handle? The shortcut Get developers exposed to open source way of doing things OpenStack offers Upstream University, two days free training before Summits Get legal clearance for devs to do work upstream Give them free time to spend upstream, 80/20 Have them do code reviews to get karma
- 34. What Corporations Can Gain Less “your contribution is late or missing tests” Contributors will know deadlines and best practices Less “thank you but we don't like how you implemented it” Contributors will have circulated design ideas before proposing code More “Well done, we wish someone did this before” Teams will fix issues proactively More karma to get past the dreaded Feature Freeze Tech Leaders will know that your developers know how to deliver good code on time and be more willing to grant exceptions
- 35. The Short Answer The license has very little to do with this (really) Get ready to change the organization Tweak how you develop products and serve customers Think outside corporate boundaries Think long term
- 36. All text and image content in this document is licensed under the Creative Commons Attribution-Share Alike 3.0 License (unless otherwise specified). "OpenStack" is a registered trademark. The logos, wordmark and icons are subject to international laws and its use is subject to the trademark policy. Questions? Comments? Stefano Maffulli @smaffulli stefano@openstack.org
- 37. All text and image content in this document is licensed under the Creative Commons Attribution-Share Alike 3.0 License (unless otherwise specified). "OpenStack" is a registered trademark. The logos, wordmark and icons are subject to international laws and its use is subject to the trademark policy. Credits and More Content https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/how-do-you-ag https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/building-a-cont http://upload.wikimedia.org/wikipedia/commons/4/4a/Artist%27s_concept_of_collision_at_HD_172555.jpg http://upload.wikimedia.org/wikipedia/commons/c/c8/Shinkansen_tokyo.jpg http://activity.openstack.org/dash/browser/scm-companies.html http://www.iriweb.org/Public_Site/RTM/Volume_55_Year_2012/July-August_2012/Open_Innovation_Where_We http://en.wikipedia.org/wiki/Burnout_%28vehicle%29#mediaviewer/File:Zeeboid_burnout.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Metronome_Nikko.jpg/220px-Metronome_Nikko.jpg https://www.flickr.com/photos/museemccordmuseum/2918567169/ https://www.flickr.com/photos/movingsimplified/5127019316/ https://www.flickr.com/photos/amagill/38961674/
Editor's Notes
- 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.
- 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
- 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?
- 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.
- 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
- 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
- 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.
- What people usually notice are people yelling on mailing lists, conflicts of all sorts and failure. Collaboration becomes a trainwreck
- How does open collaboration work? The OpenStack example
- 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
- 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.
- 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.
- If you really want to see the details of an individual patch
- Companies trying to join a project like openstack face a scale issue
- And they face a velocity issue
- There is a complexity issue And it doesn't matter whether you look at OpenStack as layers or
- 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.
- Joining a large, rapidly changing, complex project like OpenStack is like running with bulls.
- I've been doing a lot of research in the past months to find out which companies are joining this huge party.
- 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.
- 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.
- 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.
- 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.
- How to avoid spinning your wheels?
- 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.
- 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.
- 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.
- Favor asynchronous communication Even if your team is in the same timezone, expect you'll have to interact with people somewhere else
- 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.
- 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.
- 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).
- 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.
- To recap.
- 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.