Skip to content

Commit 36ac3c4

Browse files
authored
Created scenarios.md
1 parent 1464431 commit 36ac3c4

File tree

1 file changed

+189
-0
lines changed

1 file changed

+189
-0
lines changed

introduction/scenarios.md

Lines changed: 189 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,189 @@
1+
#Inner source scenarios
2+
3+
Where inner source methodology is being used? Which kind of companies are already
4+
using it?
5+
6+
In 2000, Tim O'Reilly defined inner source as "the use of open source development
7+
techniques within the corporation". Clearly this definition applies to
8+
companies developing software for their own use or to be used by
9+
third parties.
10+
11+
Some common open source development techniques are:
12+
13+
- transparent development: anyone is able to review and contribute
14+
15+
- forks are welcome: innovation is usually driven by new ideas from existing projects
16+
17+
- diverse teams: people from all around the world are able to contribute, independently of their gender,
18+
education, race, etc.
19+
20+
- transparent communication: everything, from documents to conversations, is written and
21+
stored, to allow historical review
22+
23+
Inner source, like open source, is well suited for cross-organization collaboration breaking
24+
boundaries of teams, business units and nations.
25+
26+
Beyond the obvious profile, software development companies, let's see some
27+
scenarios or situations where inner source can help.
28+
29+
## The Digital Transformation wave
30+
31+
During last years, many companies have started facing what
32+
they call their “Digital Transformation”, to become omnichannel
33+
companies[^4]. They become heavy IT users and the key transformation
34+
steps usually are defined by
35+
36+
- breaking cross-organizational silos (cultural change)
37+
38+
- adoption new IT technologies (cloud, big data, mobile, etc.)
39+
40+
The adoption of these technologies usually means that companies need
41+
to build competent “DevOps”[^5] teams. Yes, “DevOps”, the second
42+
hype-word after “Digital Transformation” of these ages.
43+
44+
“DevOps teams” share some principles with collaborative development
45+
teams in the open source world. As first described by John Willis and
46+
Damon Edwards in 2010, CALMS, standing for Culture (collaboration),
47+
Automation, Lean, Measurement, and Sharing to describe the “DevOps
48+
framework”, obviously contains terms familar to any open source
49+
developer.
50+
51+
These teams usually develop custom software solutions and deployment
52+
recipes for their companies. For small, medium enterprises (SME) this
53+
could be useful and easy to manage. But, what happens when the company
54+
has several DevOps teams around the world? How can they ensure a maximum
55+
code/knowledge reuse across the organization?
56+
57+
We have seen companies facing the same problem with different solutions
58+
due to the lack of cross-organizational transparent and collaborative
59+
methodology.
60+
61+
## The World of Silos
62+
63+
In some cases, there is a corporate head or central unit that decides
64+
the technology for the rest of business units. When these business units
65+
adopt the technology, they usually need to customize it, ending with
66+
something slightly different to the orginal product. While the central
67+
unit evolves its product in their “closed silo”, the other units are
68+
probably doing the same in their “silos”. The result? The adoption of
69+
any update of the “core product” is a nightmare.
70+
71+
In other cases, business units behave as independent companies. Each one
72+
uses their own IT architecture, ending with an inefficient management of
73+
resources caused by multiplication of technologies, developments, etc.
74+
75+
Collaborative development in open source ecosystems has been used several
76+
times as an example of how these methodologies can break silos between
77+
companies that might be even market competitors. Those companies have
78+
been able to share knowledge and resources with a common goal . If competitors can
79+
collaborate to build technology in which their business rely on, why
80+
could not corporate business units do the same if they have corporate
81+
succes as mission?
82+
83+
## The start-ups bubble
84+
85+
Many people might discuss if we are living a “start-ups bubble” or not,
86+
but we are clearly surrounded by news about how a group of few people go
87+
from a garage to a multinational company in a few years through
88+
investment rounds.
89+
90+
Our experience tell us that opening offices abroad is always a
91+
challenge, and managing development teams growing that fast can be a
92+
serious problem.
93+
94+
The lack of effective and transparent communication channels and
95+
documented procedures, might make harder any new employee on-boarding
96+
and to be engaged with the company.
97+
98+
On the other hand, recently created companies have been born taking
99+
advantage of the existing IT solutions to provide omnichannel services.
100+
They are used to work under “DevOps culture” and it might be easier for
101+
them to adopt a common cross-organizational methodology that allow
102+
transparency and collaboration.
103+
104+
## Disengagement at work
105+
106+
If previous scenarios are familiar to you, probably you don’t feel
107+
engaged at work. Don’t worry, you are not alone. According to World
108+
Economic Forum [^6] 70% of employees say they are disengaged at work.
109+
110+
In the same article, it says that “Research from the University of
111+
California found that motivated employees were 31% more productive, had
112+
37% higher sales, and were three times more creative than demotivated
113+
employees. They were also 87% less likely to quit, according to a
114+
Corporate Leadership Council study on over 50,000 people”.
115+
116+
Towers Watson[^7] found that companies with engaged employees produced
117+
19.2% more operative incomes in one year, but companies with worse
118+
engagement operative incomes get reduced by 32.7%.
119+
120+
It was Daniel Pink in his book "Drive"[^8] who argues that human motivation is
121+
largely intrinsic. The aspects of this motivation can be divided into
122+
123+
- autonomy, typical for OSS projects developers that are self-managed
124+
125+
- mastery, as the desire to improve developer skills to improve the project they are involved in
126+
127+
- purpose, defined as mission in many OSS projects
128+
129+
These aspects are key for software developers motivation, since their tasks
130+
involve cognitive skills, decision-making, creativity, or higher-order thinking.
131+
132+
## Adopting open source development principles
133+
134+
Briefing, there are several scenarios found in companies with an strong
135+
IT factor:
136+
137+
- “Silos Culture” avoiding cross-organizational transparency
138+
139+
- Inefficient resources management
140+
141+
- Disengagement at work
142+
143+
By adopting OSS development principles, companies are adopting:
144+
145+
- Governance model with policies to self-manage their projects under a
146+
collaborative methodology
147+
148+
- Transparent communication channels to break silos
149+
150+
- Meritocracy, or do-cracy, for developers, who become engaged “contributors”
151+
(autonomous, willing to improve their skills and focused in project purpose)
152+
153+
- New roles for project managers, empowering their soft skills for
154+
people/community management
155+
156+
These principles will help the companies on:
157+
158+
- Effective resources management, with better code/knowledge reuse
159+
and cost sharing accross the different units
160+
161+
- Faster technology innovations/improvements, since the code is
162+
developed collaboratively and transparently by interested people and
163+
units
164+
165+
- Empowered employees, increasing engagement by letting them to be
166+
part of companies development roadmap
167+
168+
- Higher inner-innovation, by allowing employees to propose new ideas
169+
implementation based on company’s technology/knowledge
170+
171+
Adopting open source development principles inside your company is the main
172+
definition for inner source. If you have already
173+
decided, or have started to adopt Inner Source in your company, this
174+
book will provide you some insights about how you can track the status
175+
of your path.
176+
177+
“Collecting data is only the first step toward wisdom, but sharing data
178+
is the first step toward community.” – Henry Lewis Gates (professor at
179+
Harvard)
180+
181+
[^4]: https://en.wikipedia.org/wiki/Omnichannel
182+
183+
[^5]: https://en.wikipedia.org/wiki/DevOps
184+
185+
[^6]: https://www.weforum.org/agenda/2016/11/70-of-employees-say-they-are-disengaged-at-work-heres-how-to-motivate-them/
186+
187+
[^7]: http://www.towerswatson.com/DownloadMedia.aspx?media=%7B1EBA6F1E-B1E7-4F0A-A9F7-D828C4D8B2AE%7D
188+
189+
[^8]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us

0 commit comments

Comments
 (0)