Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Inner Source 101 - GWO2016

1,044 views

Published on

Slides from my Inner Source 101 presentation at Great Wide Open 2016. Using the lessons learned from Open Source to enhance Enterprise IT via inner-sourcing

Published in: Technology
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...♥♥♥ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Your opinions matter! get paid BIG $$$ for them! START NOW!!..  https://tinyurl.com/make2793amonth
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...★★★ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...◆◆◆ https://tinyurl.com/realmoneystreams2019
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Inner Source 101 - GWO2016

  1. 1. Jim Jagielski @jimjag Inner Source 101 AKA: Lessons Learned from Open Source for the Enterprise
  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. Introduction ➡ 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
  4. 4. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles ➡ Communication ➡ Transparency ➡ Collaboration ➡ Community ➡ Meritocracy
  5. 5. 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
  6. 6. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Principles: Transparency ➡ Public and Open ➡ Inclusion ➡ Reuse ➡ You can only reuse what you can see ➡ Connections ➡ Quality/Security ➡ More eyeballs mean better quality ➡ Measurement ➡ Transparency enables measurement ➡ Transparency ➾ Collaboration
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Techniques: Community ➡ Tech-talks ➡ Mentoring ➡ Cross-team events ➡ Break down silos
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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”
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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”
  22. 22. 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
  23. 23. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Final Thoughts ➡ 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
  24. 24. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Thanks! Twitter: @jimjag Emails:
 jim@jaguNET.com
 jim@apache.org
 jim.jagielski@capitalone.com http://www.slideshare.net/jimjag/ Thx to Phil Steitz for inspiration and supplemental information
  25. 25. This work is licensed under a Creative Commons Attribution 3.0 Unported License. Backup Slides

×