It was 2011 when Marc Andreessen wrote his famous article, “Why Software is eating the World”. By that time, Linux Kernel was already 20 years old, developed under an open collaborative model by hundreds of developers from different companies, and some even contributing during their spare time. Linux can be found in almost any kind of device, from IoT and car components, to super computing cloud hardware, without forgetting one of the most used mobile operating systems in the market.
And Linux is just one example of how a free, open source software (OSS) project has evolved from one single idea in one single person’s head to multiple applications in many different fields and sectors. Each application has improved it over time, thanks to its open collaborative development methodology.
Almost 6 years later, we can assure that free, open source software (OSS) projects have succeed in the IT development ecosystem. We can see companies adopting OSS technologies and people contributing to OSS from different companies and even during their spare time.
How has OSS reached the level of innovation we have nowadays? How has it reached the market acceptance we see nowadays? How has it engaged so many people and organizations to contribute to it?
It’s a teamwork effort and quoting John Wooden (former UCLA Bruins basketball coach) in IBM Linux commercial :
“A player who makes a team great is more valuable than a great player. Losing yourself in the group for the good of the group, that’s teamwork.”
Since the collaboration methodologies used in OSS projects are providing high quality innovative technology thanks to engaged development communities, why not applying same methodologies inside your company? That's InnerSource!
If you haven't decided yet to apply InnerSource in your company, we recommend you start reading "Getting Started with InnerSource" by Andy Oran. After that, or if you have already decided to start the InnerSource path, this book will give you better understanding of InnerSource scenarios, framework and management skills.
InnerSource software development takes its principles from the open source software development culture. Jim Jagielski, from The Apache Software Foundation, has listed them as:
Culture
Communication
Transparency
Collaboration
Community
Meritocracy
As an organization willing to adopt InnerSource methodology, the first step is to look how close are organization's principles with these open source ecosystem principles, and work on minimizing the deltas with them.
https://www.youtube.com/watch?v=x7ozaFbqg00
http://www.slideshare.net/jimjag/inner-source-enterprise-lessons-from-the-open-source-community
#InnerSource scenarios
Where InnerSource methodology is being used? Which kind of companies are already using it?
In 2000, Tim O'Reilly defined InnerSource as "the use of open source development techniques within the corporation". Clearly this definition applies to companies developing software for their own use or to be used by third parties.
Some common open source development techniques are:
transparent development: anyone is able to review and contribute
forks are welcome: innovation is usually driven by new ideas from existing projects
diverse teams: people from all around the world are able to contribute, independently of their gender, education, race, etc.
transparent communication: everything, from documents to conversations, is written and stored, to allow historical review
InnerSource, like open source, is well suited for cross-organization collaboration breaking boundaries of teams, business units and nations.
Beyond the obvious profile, software development companies, let's see some scenarios or situations where InnerSource can help.
During last years, many companies have started facing what they call their “Digital Transformation”, to become omnichannel . They become heavy IT users and the key transformation steps usually are defined by
breaking cross-organizational silos (cultural change)
adoption new IT technologies (cloud, big data, mobile, etc.)
The adoption of these technologies usually means that companies need to build competent “DevOps” teams. Yes, “DevOps”, the second hype-word after “Digital Transformation” of these ages.
“DevOps teams” share some principles with collaborative development teams in the open source world. As first described by John Willis and Damon Edwards in 2010, CALMS, standing for Culture (collaboration), Automation, Lean, Measurement, and Sharing to describe the “DevOps framework”, obviously contains terms familiar to any open source developer.
These teams usually develop custom software solutions and deployment recipes for their companies. For small, medium enterprises (SME) this could be useful and easy to manage. But, what happens when the company has several DevOps teams around the world? How can they ensure a maximum code/knowledge reuse across the organization?
We have seen companies facing the same problem with different solutions due to the lack of cross-organizational transparent and collaborative methodology.
In some cases, there is a corporate head or central unit that decides the technology for the rest of business units. When these business units adopt the technology, they usually need to customize it, ending with something slightly different to the original product. While the central unit evolves its product in their “closed silo”, the other units are probably doing the same in their “silos”. The result? The adoption of any update of the “core product” is a nightmare.
In other cases, business units behave as independent companies. Each one uses their own IT architecture, ending with an inefficient management of resources caused by multiplication of technologies, developments, etc.
Collaborative development in open source ecosystems has been used several times as an example of how these methodologies can break silos between companies that might be even market competitors. Those companies have been able to share knowledge and resources with a common goal . If competitors can collaborate to build technology in which their business rely on, why could not corporate business units do the same if they have corporate success as mission?
Many people might discuss if we are living a “start-ups bubble” or not, but we are clearly surrounded by news about how a group of few people go from a garage to a multinational company in a few years through investment rounds.
Our experience tell us that opening offices abroad is always a challenge, and managing development teams growing that fast can be a serious problem.
The lack of effective and transparent communication channels and documented procedures, might make harder any new employee on-boarding and to be engaged with the company.
On the other hand, recently created companies have been born taking advantage of the existing IT solutions to provide omnichannel services. They are used to work under “DevOps culture” and it might be easier for them to adopt a common cross-organizational methodology that allow transparency and collaboration.
If previous scenarios are familiar to you, probably you don’t feel engaged at work. Don’t worry, you are not alone. According to World Economic Forum 70% of employees say they are disengaged at work.
In the same article, it says that “Research from the University of California found that motivated employees were 31% more productive, had 37% higher sales, and were three times more creative than demotivated employees. They were also 87% less likely to quit, according to a Corporate Leadership Council study on over 50,000 people”.
Towers Watson found that companies with engaged employees produced 19.2% more operative incomes in one year, but companies with worse engagement operative incomes get reduced by 32.7%.
It was Daniel Pink in his book "Drive" who argues that human motivation is largely intrinsic. The aspects of this motivation can be divided into
autonomy, typical for OSS projects developers that are self-managed
mastery, as the desire to improve developer skills to improve the project they are involved in
purpose, defined as mission in many OSS projects
These aspects are key for software developers motivation, since their tasks involve cognitive skills, decision-making, creativity, or higher-order thinking.
https://en.wikipedia.org/wiki/DevOps
http://www.towerswatson.com/DownloadMedia.aspx?media=%7B1EBA6F1E-B1E7-4F0A-A9F7-D828C4D8B2AE%7D
By adopting InnerSource methodology and principles, organizations get:
Effective resources management, with better code/knowledge reuse and cost sharing across the different units
Faster technology innovations/improvements, since the code is developed collaboratively and transparently by interested people and units
Empowered employees, increasing engagement by letting them to be part of companies development roadmap
Higher inner-innovation, by allowing employees to propose new ideas and implementations based on company’s technology/knowledge
But any project, even open source ones, need a framework that support them defining:
clear policies for contributors, to manage meritocracy (or do-cracy)
tools and communication channels
community culture
who pays it?
metrics and KPIs
Let's introduce the InnerSource framework.
According to the Business Dictionary, governance is defined as:
Establishment of policies, and continuous monitoring of their proper implementation, by the members of the governing body of an organization. It includes the mechanisms required to balance the powers of the members (with the associated accountability), and their primary duty of enhancing the prosperity and viability of the organization
In open source, governance is described in the "governance model" document, defined by OSSWatch as:
A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community
Usually the governance model is a written document containing:
project goals
work, management and collaboration infrastructures definition
people roles and responsibilities definitions
community support mechanisms
decision making process policies description
contribution process policies description
monitoring policies and mechanisms description
By technical infrastructure we describe the tools used by InnerSource developers for their daily work. Usually, this tools cover:
Source code management systems
Issue/tasks tracking systems
Forums or mailing lists, and "questions and answers" forums
Chat or instant messaging tools
Continuous integration systems
Document/knowledge management systems (wikis)
Creating an engaged community is one of the key points for open source projects success and sustainability. Same principle applies for InnerSource projects.
Managing a community is different from traditional development teams management, so project managers need to adapt their skills to the new scenario.
Open source communities are very flat organizations where leadership is usually more important than formal power. Companies adopting InnerSource need to adapt their organizational structure to a flatter one.
In a perfect InnerSource scenario, and based in David Pink quote you should pay enough “to take the issue of money off the table.”
But we usually don't live in perfect worlds, and there are several scenarios where financial support for InnerSource projects are critical:
payment in different geographical regions
employees working in a mix of InnerSource and non-InnerSource projects
cost sharing between different business units with their own budget
projects developed by a mix of company employees and subcontractors
Again, open source provides some examples of how to get financial support for their projects, and organizations like Linux Foundation, Apache Software Foundation, etc. could work as reference, translating their "foundation" principles to our companies.
Last but not least, if we are speaking about management, to measure becomes a basic skill for us.
Beyond collecting data, managers need to understand the goals of the organization and how the gathered data can help them to achieve such goals. They also need to take care of how they share that data with the teams, and what they want to achieve.
“Collecting data is only the first step toward wisdom, but sharing data is the first step toward community.” – Henry Lewis Gates (professor at Harvard)
Open measurement gives a lot of benefits for our InnerSource community:
awareness, it allows us to understand who we are, what we are doing, etc.
governance check, monitoring policies implementation
transparency, as trust generator for third parties and fairness for our InnerSource community
J. Manrique López ()
Daniel Izquierdo ()