Open Development in the Enterprise
- 1. Open Development in the Enterprise November 6, 2008 Sunday, February 6, 2011
- 2. Introduction What can corporate IT learn from leading open development communities? Both principles and techniques offer value Challenges must be overcome to realize value Sunday, February 6, 2011
- 3. Principles Transparency Decision-making and actions are observable Events of interest are published and recorded Meritocracy Influence on decisions is based on merit Merit is earned in public Community Common interest Common experience / identity “Community before code” Sunday, February 6, 2011
- 4. Techniques Open Standards Using open standards in systems design and standards-based tools for development Collaboration Infrastructure Systems supporting communication and coordination: repositories, trackers, forums, build tools Meritocratic Governance Merit determines influence on decisions Community-based governance structures Sunday, February 6, 2011
- 5. Challenges Choosing the right opportunities “Open everything” does not work Clue Resistance to change to loss of control Rewarding merit Business focus Accountability Control Sunday, February 6, 2011
- 6. Principles Sunday, February 6, 2011
- 7. Principles - Transparency Collaboration Transparency invites collaboration Reuse You can only reuse what you can see Quality More eyeballs mean better quality Measurement Transparency enables measurement Sunday, February 6, 2011
- 8. Transparency Collaboration Transparent processes enable people to see connections Transparent decision-making encourages contribution and improves leverage Transparency encourages feedback and dialogue Example: infrastructure planning and development Sunday, February 6, 2011
- 9. Transparency Reuse People can reuse assets they can find and understand. Transparency increases both the likelihood that people will find assets and that they will understand them. Transparency means you can see where development is headed so you can plan reuse. Transparency can give confidence in quality, making reuse more likely. Example: Transparent bug / enhancement tracking, feature lists, release plans makes reuse of shared components easier to plan and execute Sunday, February 6, 2011
- 10. Transparency Quality "Too enough eyeballs, all bugs are shallow" Open discussion can lead to better decisions Errors may be seen early Transparency encourages and facilitates peer review “Lurkers” sometimes see things that closed group may miss and they learn things by observing Examples: Opening source and dev process for common components; peer reviews; problem management; operations Sunday, February 6, 2011
- 11. Transparency Measurement Transparency makes process visible Development events can be tracked Active and inactive people, code, sub-communities can be discovered Metrics can be less subject to debate when derived from transparent processes Examples: Contributions to shared assets; roadmap progress; source quality metrics; test execution metrics; problem management Sunday, February 6, 2011
- 12. Principles - Meritocracy Technical decisions made by technical experts Better informed decisions Role models Merit provides examples Earned authority “Natural” leadership Sunday, February 6, 2011
- 13. Meritocracy Better Decisions Better information Better analysis Faster consensus Less prone to vendor / hype distortion Less prone to stupid groupthink Not the rule in corporate settings today, more common in startups / small companies Examples: technology product selection; technology standards; organization structure Sunday, February 6, 2011
- 14. Meritocracy Role Models People with community-earned merit provide examples of behaviors that the community likes Merit-earning people provide examples of community contributions that have merit Imitating people with merit helps others develop and usually leads to good results Examples: peer reviews; open certification process; formal mentoring; committer / PMC member concepts for shared assets Sunday, February 6, 2011
- 15. Meritocracy Earned Authority When leaders earn merit and gain authority as a consequence, their authority is perceived as earned rather than by title or circumstance. People follow these leaders. People follow leaders whose authority is based on merit that they know about. People support decisions made by people with earned authority. Examples: major refactoring / uplift; service restoration; process change; talent pipeline / promotions; strategy and standards Sunday, February 6, 2011
- 16. Principles - Community Loyalty Community breeds loyalty Durability Communities can create durable assets, processes and culture Shared vision Vision grounded in common experience and personal connection Sunday, February 6, 2011
- 17. Community Loyalty Loyal people contribute Loyal people support one another Loyal people work out conflicts and compromise to support the community Loyalty begets loyalty Examples: retention; service restoration; crunch time; managing conflict Sunday, February 6, 2011
- 18. Community Shared Vision Community shares experience Vision can be developed in the community Vision guides community and holds it together Vision helps community adapt to change Examples: transformation plans; refactoring; innovation Sunday, February 6, 2011
- 19. Community Durability Communities can survive individual departures Community developed assets can be revived / restarted when time is right Community developed assets are robust against changing requirements Examples: shared code components; architecture communities Sunday, February 6, 2011
- 20. Techniques Sunday, February 6, 2011
- 21. Techniques Open Standards Using open standards in systems design and standards-based tools for development Collaboration Infrastructure Systems supporting communication and coordination: repositories, trackers, forums Meritocratic Governance Merit determines influence on decisions Community-based governance structures Sunday, February 6, 2011
- 22. Techniques - Open Standards Faster ramp-up Standards provide common background Easier setup Easier to get started, get up to speed Interoperability Key to success in heterogeneous environments Sunday, February 6, 2011
- 23. Techniques - Collaboration Infrastructure Communications Support asynchronous, geographically dispersed collaboration, fewer meetings Repositories Enable transparency, discoverability Trackers Coordinate collaborative work, transparency Build tools Enable consistent, independent, repeatable builds; support process discipline, quality assurance, productivity,ramp-up Sunday, February 6, 2011
- 24. Techniques - Meritocratic Governance Decisions Influence on decisions determined by merit Structures Governance structures supporting merit-based decision-making Examples: PMC managing roadmap / stds, shared components; user/contributor/committer roles for common code as well as strategy / standards content; review and approval of changes to standards, roadmaps, shared assets; peer voting on releases Sunday, February 6, 2011
- 25. Challenges Sunday, February 6, 2011
- 26. Choosing the Right Opportunities Good Bad Ugly Building Open development Open development communities that in specialized areas of shared assets have nothing to do with small teams with day jobs Meritocracy Meritocratic decision-making Merit earned and principles integrated process, but acknowledged, but into performance decisions not not rewarded management binding Open development Open development Open development infrastructure process introduced principles mandated introduced as part of with no with no process or process infrastructure infrastructure improvement support support Sunday, February 6, 2011
- 27. Choosing the Right Opportunities Transparency Open Standards Almost always a good thing, Always but need to be careful to avoid distraction / low signal/noise Collaboration Infrastructure Take “appropriate Meritocracy technology” approach. Can The more technical the domain, be a vector for planting the the more valuable this is. open development meme Needs to be inclusive and Meritocratic Governance harmonized with hierarchy. Apply selectively, starting in Community technical domains with Like transparency – always leaders who already operate good in principle, but can have consistently with the ideas. low / no value if not conceived Formalize criteria. and nurtured correctly Sunday, February 6, 2011
- 28. Clue Community is not the same as team Contribution is work Community requires investment Transparency is not a threat Collaboration means compromise Driving results means driving consensus Sunday, February 6, 2011
- 29. Resistance to Change If it ain't broke... Communication can be annoying at first Need to learn new tools and processes Closed processes and decision-making are the norm Administrivia can get in the way and provide a convenient excuse to defer / delay Sunday, February 6, 2011
- 30. Resistance to Loss of Control Open development can be directed, but can’t be micro-managed Schedules and timelines “Owning” decisions Fear of failure Accountability, reporting, leadership communications Sunday, February 6, 2011
- 31. Meritocracy / Rewards Mismatch Reward system may not be based on merit Merit needs to be rewarded to proliferate Merit needs to be rewarded to be respected Sunday, February 6, 2011
- 32. Maintaining Accountability Community ownership does not guarantee owners are always available and responsive Not always clear who owns decisions or when decisions have been made Easy to blame lack of engagement / community support for bad decisions or work products Control and support responsibilities need to be managed explicitly Sunday, February 6, 2011
- 33. Maintaining Control Communities are harder to direct and focus than individuals Company value needs to drive community, not vice-versa Roadmap needs to be explicit and directive (another reason it is good for this to be an open development product) Timelines, feature sets, quality, packaging and deployment objectives have to be explicit and accepted as largely “exogenous” Sunday, February 6, 2011
- 34. Maintaining Business Focus Community interest must align with company interest Business leaders have to be welcome and engaged in community Merit is not just technical and has to be linked to business results Open development projects need to deliver value – “show value early, show value often” Open development should not be used as a means to invest in projects that have weak or no business case Sunday, February 6, 2011
- 35. Questions? Sunday, February 6, 2011