Inner Source: Enterprise Lessons from the Open Source Community.

824 views

Published on

Slides from my Inner Sourcing talk from ApacheCon NA 2016. Inner Sourcing is using the methods and techniques of successful open source projects inside Enterprise IT.

Published in: Technology

Inner Source: Enterprise Lessons from the Open Source Community.

  1. 1. Jim Jagielski @jimjag Inner Sourcing Enterprise Lessons Learned from the Open Source Community
  2. 2. This work is licensed under a Creative Commons Attribution 3.0 Unported License. About Me ➡ Apache Software Foundation ➡ Co-founder, Director, Member and Developer ➡ Director ➡ Outercurve, MARSEC-XL, OSSI, OSI (ex)… ➡ Developer ➡ Mega FOSS projects ➡ O’Reilly Open Source Award: 2013 ➡ European Commission: Luminary Award ➡ Sr. Director: Tech Fellows: Capital One
  3. 3. This work is licensed under a Creative Commons Attribution 3.0 Unported License. What is Open Source? ➡ Basically, it’s a “new” way to develop, license and distribute code ➡ Actually, there was “open source” even before it was called that ➡ The key technologies behind the Internet and the Web and the Cloud are all Open Source based ➡ Brings Scientific Method to IT
  4. 4. This work is licensed under a Creative Commons Attribution 3.0 Unported License. What is Open Source? ➡ Open Source Licensing ➡ OSI and/or Free Software Foundation (FSF) Approved ➡ Free Software ➡ As in Free Speech, not Free Beer ➡ Open Source Methodology (secondary) ➡ Community/Governance types ➡ Many consider this just as important as the license
  5. 5. This work is licensed under a Creative Commons Attribution 3.0 Unported License. What is Open Source? ➡ Also called Free Software ➡ But the word “Free” confuses some people ➡ FOSS: Free and Open Source Software ➡ FLOSS: Free/Libre Open Source Software ➡ Pretty much, all mean the same thing ➡ The name can cause “religious” or “philosophical” debates, but in government and industry, Open Source is the more widely used term.
  6. 6. This work is licensed under a Creative Commons Attribution 3.0 Unported License. What is Open Source? ➡ Basic tenets (related to licenses): ➡ Access to the source code (the code is Open and Free) ➡ Ability to use the source code (run it and/or leverage it) ➡ Ability to modify the source code ➡ Ability to distribute the (modified) source code ➡ Open Source “methodology”/philosophy ➡ This is what Inner Sourcing is all about
  7. 7. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Community ➡ AKA: Governance ➡ Defines how the community operates ➡ How conflicts are resolved ➡ Growth path of the community ➡ code ➡ members ➡ Again, 3 main types
  8. 8. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Walled Garden “All your base are belong to us.”
  9. 9. This work is licensed under a Creative Commons Attribution 3.0 Unported License. BDFL “Supreme executive power derives from a mandate from the masses, not some farcical aquatic ceremony.”
  10. 10. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Meritocracy “Out of Chaos comes Order”
  11. 11. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Inner Sourcing ➡ What can corporate IT learn from leading open development communities? ➡ Both principles and techniques offer value ➡ Understanding principles allows you to alter techniques ➡ Challenges must be overcome to realize success
  12. 12. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Why? ➡ Gain efficiencies by leveraging resident talent to its fullest ➡ Develop better software faster through collaboration ➡ Reduce costs through technology standardization and reuse ➡ Bring products to market faster ➡ Increase developer engagement and innovation through social creativity ➡ Attract and retain higher quality talent
  13. 13. This work is licensed under a Creative Commons Attribution 3.0 Unported License. How? ➡ “Building a boat isn’t about weaving canvas, forging nails, or reading the sky. It’s about giving a shared taste for the sea, by the light of which you will see nothing contradictory but rather a community of love.”
 ➡ “If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” ― Antoine de Saint-Exupéry
  14. 14. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles ➡ Culture ➡ Communication ➡ Transparency ➡ Collaboration ➡ Community ➡ Meritocracy
  15. 15. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Culture ➡ Inner-sourcing is a cultural mind-shift ➡ Create an expected set of behaviors ➡ Must be truly engaged ➡ Must be truly accepted ➡ Culture ➾ Communication
  16. 16. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Communication ➡ Is core and foundational ➡ Everything builds on this ➡ Open and asynchronous ➡ Doesn’t disenfranchise anyone ➡ Archivable ➡ Maintains history and allows ebb/flow ➡ Document tribal knowledge ➡ Communication ➾ Transparency
  17. 17. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Transparency ➡ Reinforces and Enables Public and Open mindset ➡ Inclusion ➡ Reuse ➡ You can only reuse what you can see ➡ Quality/Security ➡ More eyeballs mean better quality ➡ Measurement ➡ Transparency enables measurement ➡ Transparency ➾ Collaboration
  18. 18. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Collaboration ➡ Common Vision ➡ Common Goal ➡ See connections ➡ Encourages contribution and improves leverage ➡ Encourages feedback and dialogue ➡ Collaboration ➾ Community
  19. 19. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Community ➡ Loyalty ➡ Community breeds loyalty ➡ Durability ➡ Communities can create durable assets, processes and culture ➡ Health ➡ Feedback and Dialogue ➡ Community ➾ Meritocracy
  20. 20. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Meritocracy ➡ Technical decisions made by technical experts ➡ Better informed decisions ➡ Role models ➡ Merit provides examples ➡ Earned authority ➡ “Natural” leadership ➡ Known path and “rewards” ➡ Meritocracy ➾ Communication
  21. 21. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques ➡ Culture ➡ Model transparency in your community; all decisions and actions done in the open ➡ Embrace a collaborative development model that promotes self-governance and evaluates contributions based on merit ➡ Value all roles in the community and provide recognition - contributors are just as valued as committers ➡ Model and promote our Code of Conduct ➡ Process ➡ Make it easy to participate in your community - streamline contributions and enable collaboration, and set clear expectations for software development ➡ Provide clear and concise documentation ➡ Be responsive to your community and provide meaningful feedback to contributors
  22. 22. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques ➡ Collaboration Infrastructure ➡ Systems supporting communication and coordination: repositories, trackers, forums, build tools ➡ Open Standards ➡ Using open standards in systems design and standards-based tools for development ➡ Meritocratic Governance ➡ Merit determines influence on decisions ➡ Community-based governance structures
  23. 23. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques: Communication and Transparency ➡ E-Mail lists ➡ Avoid F2F meetings ➡ Always bring meeting discussions back to list ➡ IRC/Slack/Hipchat as backups ➡ Communications ➡ Encourage larger audiences ➡ Not just “core” teams ➡ Encourage “lurkers” ➡ All development done on-list
  24. 24. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques: Collaboration ➡ Repositories ➡ Enable discoverability ➡ All can read, limit write ➡ Trackers ➡ Coordinate collaborative work, transparency ➡ Build and Test tools ➡ Enable consistent, independent ➡ repeatable builds ➡ support process discipline, quality assurance, productivity,ramp-up ➡ Sharing / re-use
  25. 25. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques: Community ➡ Tech-talks ➡ Mentoring ➡ Cross-team events ➡ Break down silos
  26. 26. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques: Meritocracy ➡ 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
  27. 27. This work is licensed under a Creative Commons Attribution 3.0 Unported License. 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
  28. 28. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Challenges ➡ Resistance ➡ Choosing the right opportunities ➡ “Open everything” does not work ➡ Rewarding merit ➡ Business focus ➡ Accountability ➡ Control
  29. 29. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Resistance ➡ 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 ➡ can provide a convenient excuse to defer / delay ➡ Fear of loss of control and/or “ownership”
  30. 30. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Choosing the Right Opportunities Good Bad Ugly Open development of shared assets Open development in specialized areas with small teams Building communities that have nothing to do with day jobs Meritocracy principles integrated into performance management Meritocratic decision- making process, but decisions not binding Merit earned and acknowledged, but not rewarded Open development infrastructure introduced as part of process improvement Open development process introduced with no infrastructure support Open development principles mandated with no process or infrastructure support
  31. 31. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Meritocracy / Rewards Mismatch ➡ Defining “merit” can be hard ➡ Reward system may not be based on merit ➡ Path to merit must be clear and open ➡ Merit needs to be rewarded to proliferate ➡ Merit needs to be rewarded to be respected
  32. 32. This work is licensed under a Creative Commons Attribution 3.0 Unported License. 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 ➡ Developers get the 3am call
  33. 33. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Maintaining Control ➡ Communities are harder to direct and focus than individuals ➡ Merit can be invaluable here ➡ Company value needs to drive community, not vice-versa ➡ Roadmap needs to be explicit and direct ➡ Timelines, feature sets, quality, packaging and deployment objectives have to be explicit ➡ accepted as largely “external”
  34. 34. This work is licensed under a Creative Commons Attribution 3.0 Unported License. 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 ➡ Projects need to deliver value – “show value early, show value often” ➡ Inner Sourcing should not be used as a means to invest in projects that have weak or no business case
  35. 35. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Final Thoughts ➡ Community is not the same as team ➡ self organizing ➡ self identifying ➡ Contribution is work ➡ Community requires investment ➡ Transparency is not a threat ➡ Collaboration means compromise ➡ Driving results means driving consensus

×