Scenarios
#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.
The digital transformation wave
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.
The world of silos
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?
The start-ups bubble
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.
Disengagement at work
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
Last updated