inner source 101 - gwo2016
TRANSCRIPT
Jim Jagielski @jimjag
Inner Source 101
AKA: Lessons Learned from Open Source for the Enterprise
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
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
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Principles➡ Communication ➡ Transparency ➡ Collaboration ➡ Community ➡ Meritocracy
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
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
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
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
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
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
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
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
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Techniques: Community➡ Tech-talks ➡ Mentoring ➡ Cross-team events ➡ Break down silos
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
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
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
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”
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
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
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
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”
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
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
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Thanks!
Twitter: @jimjag
Emails:[email protected]@apache.org [email protected]
http://www.slideshare.net/jimjag/
ThxtoPhilSteitzforinspirationandsupplementalinformation
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Backup Slides