Inner Source: Enterprise Lessons from the Open Source Community

Jim Jagielski @jimjag

Inner Sourcing Enterprise Lessons Learned from

the Open Source Community

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


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


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


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.


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


Community➡ AKA: Governance

➡ Defines how the community operates ➡ How conflicts are resolved ➡ Growth path of the community

➡ code ➡ members

➡ Again, 3 main types


Walled Garden

“All your base are belong to us.”


BDFL

“Supreme executive power derives from a mandate from the masses, not some farcical aquatic ceremony.”


Meritocracy

“Out of Chaos comes Order”


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


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


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


Principles➡ Culture ➡ Communication ➡ Transparency ➡ Collaboration ➡ Community ➡ Meritocracy


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


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


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


Principles: Collaboration➡ Common Vision ➡ Common Goal ➡ See connections ➡ Encourages contribution and improves leverage ➡ Encourages feedback and dialogue ➡ Collaboration ➾ Community


Principles: Community➡ Loyalty

➡ Community breeds loyalty

➡ Durability ➡ Communities can create durable assets, processes and culture

➡ Health ➡ Feedback and Dialogue ➡ Community ➾ Meritocracy


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


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


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


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


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


Techniques: Community➡ Tech-talks ➡ Mentoring ➡ Cross-team events ➡ Break down silos


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


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


Challenges➡ Resistance ➡ Choosing the right opportunities

➡ “Open everything” does not work

➡ Rewarding merit ➡ Business focus

➡ Accountability ➡ Control


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”


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


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


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


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”


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


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

Technology

Inner Source: Enterprise Lessons from the Open Source Community