Skip to content

Commit ed8771f

Browse files
authored
Merge pull request #1 from jsmanrique/master
Added partial Introduction
2 parents 28b2f70 + d5daec1 commit ed8771f

File tree

4 files changed

+341
-0
lines changed

4 files changed

+341
-0
lines changed

introduction/authors.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
# Authors
2+
3+
- J. Manrique López ([Bitergia](http://bitergia.com))
4+
5+
## Reviewers
6+
7+
- Daniel Izquierdo ([Bitergia](http://bitergia.com))

introduction/framework.md

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
# Inner source framework
2+
3+
Adopting inner source methodology help companies on:
4+
5+
- Effective resources management, with better code/knowledge reuse
6+
and cost sharing accross the different units
7+
8+
- Faster technology innovations/improvements, since the code is
9+
developed collaboratively and transparently by interested people and
10+
units
11+
12+
- Empowered employees, increasing engagement by letting them to be
13+
part of companies development roadmap
14+
15+
- Higher inner-innovation, by allowing employees to propose new ideas
16+
implementation based on company’s technology/knowledge
17+
18+
But any project, even open source ones, need a framework
19+
that support them defining:
20+
21+
- clear policies for contributors, to manage meritocracy (or do-cracy)
22+
23+
- tools and communication channels
24+
25+
- community culture
26+
27+
- who pays it?
28+
29+
- metrics and KPIs
30+
31+
Let's introduce the *inner source framework*.
32+
33+
## Governance
34+
35+
According to the Business Dictionary, governace is defined as:
36+
37+
>Establishment of policies, and continuous monitoring
38+
>of their proper implementation, by the members of the
39+
>governing body of an organization. It includes the
40+
>mechanisms required to balance the powers of the
41+
>members (with the associated accountability), and
42+
>their primary duty of enhancing the prosperity and
43+
>viability of the organization
44+
45+
In open source, governance is described in the "governance
46+
model" document, defined by OSSWatch[^1] as:
47+
48+
>A governance model describes the roles that project participants
49+
>can take on and the process for decision making within the project.
50+
>In addition, it describes the ground rules for participation in the
51+
>project and the processes for communicating and sharing within
52+
>the project team and community
53+
54+
Usually the governance model is a written document containing:
55+
56+
- project goals
57+
58+
- work, management and collaboration infrastructures definition
59+
60+
- people roles and responsabilities definitions
61+
62+
- community support mechanisms
63+
64+
- decision making process policies description
65+
66+
- contribution process policies description
67+
68+
- monitoring policies and mechanisms description
69+
70+
## Technical infrastructure
71+
72+
By technical infrastructure we describe the tools used by inner source
73+
developers for their daily work. Usually, this tools cover:
74+
75+
- Source code management systems
76+
77+
- Issue/tasks tracking systems
78+
79+
- Forums or mailing lists, and "questions and answers" forums
80+
81+
- Chat or instant messaging tools
82+
83+
- Continous integration systems
84+
85+
- Document/knowledge management systems (wikis)
86+
87+
## Collaboration as cultural change
88+
89+
Creating an engaged community is one of the key points for
90+
open source projects success and sustainability. Same
91+
principle applies for inner source projects.
92+
93+
Managing a community is different from traditional development teams
94+
management, so project managers need to adapt their skills
95+
to the new scenario.
96+
97+
Open source communities are very flat organizations where
98+
leadership is usually more important than formal power.
99+
Companies adopting inner source need to adapt their
100+
organizational structure to a flatter one.
101+
102+
## Financial support
103+
104+
In a perfect inner source scenario, and based in David Pink quote
105+
you should pay enough “to take the issue of money off the table.”
106+
107+
But we usually don't live in perfect worlds, and there are several
108+
scenarios where financial support for inner projects are critical:
109+
110+
- payment in different geographical regions
111+
112+
- employees working in a mix of inner and non-inner source projects
113+
114+
- cost sharing between different business units with their own budget
115+
116+
- projects developed by a mix of company employees and subcontractors
117+
118+
Again, open source provides some examples of how to
119+
get financial support for their projects, and
120+
organizations like Linux Foundation, Apache Software Foundation, etc.
121+
could work as reference, translating their "foundation"
122+
principles to our companies.
123+
124+
## Processes measurement
125+
126+
Last but not least, if we are speaking about management, to measure becomes
127+
a basic skill for us.
128+
129+
Beyond collecting data, managers need to understand the goals of the organization
130+
and how the gathered data can help them to achieve such goals. They also
131+
need to take care of how they share that data
132+
with the teams, and what the want to achieve.
133+
134+
>“Collecting data is only the first step toward wisdom, but sharing data
135+
>is the first step toward community.” – Henry Lewis Gates (professor at
136+
>Harvard)
137+
138+
Open measurment gives a lot of benefits for our inner source community:
139+
140+
- awareness, it allows us to understand who we are, what we are doing, etc.
141+
142+
- governance check, monitoring policies implementatio
143+
144+
- transparency, as trust generator for third parties and fairness
145+
for our inner community
146+
147+
148+
[^1]: http://oss-watch.ac.uk/resources/governancemodels

introduction/introduction.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
# Introduction
2+
3+
It was 2011 when Marc Andreessen wrote his famous article, “Why Software
4+
is eating the World”[^1]. By that time, Linux Kernel was already 20
5+
years old, developed under an open collaborative model by hundreds of
6+
developers from different companies, and some even contributing during
7+
their spare time. Linux can be found in almost any kind of device, from
8+
IoT and car components, to super computing cloud hardware, without
9+
forgetting one of the most used mobile operating systems in the market.
10+
11+
And Linux is just one example of how a free, open source software (OSS)
12+
project has evolved from one single idea in one single person’s head to
13+
multiple applications in many different fields and sectors. Each
14+
application has improved it over time, thanks to its open collaborative
15+
development methodology.
16+
17+
Almost 6 years later, we can assure that free, open source software
18+
(OSS) projects have succeed in the IT development ecosystem. We can see
19+
companies adopting OSS technologies and people contributing to OSS from
20+
different companies and even during their spare time.
21+
22+
How has OSS reached the level of innovation we have nowadays? How has it
23+
reached the market acceptance we see nowadays? How has it engaged so many
24+
people and organizations to contribute to it?
25+
26+
It’s a teamwork effort and quoting John Wooden (former UCLA Bruins
27+
basketball coach) in IBM Linux comercial [^2]:
28+
29+
“A player who makes a team great is more valuable than a great player.
30+
Losing yourself in the group for the good of the group, that’s
31+
teamwork.”
32+
33+
Since the collaboration methodologies used in OSS projects are providing
34+
high quality innovative technology thanks to engaged development communities,
35+
why not applying same methodologies inside your company? That's inner source!
36+
37+
If you haven't decided yet to apply inner source in your company, we recommend you
38+
start reading "Getting Started with InnerSource"[^3] by Andy Oran. After that, or if
39+
you have already decided to start the inner source path, this book will give you better
40+
understanding of inner source scenarios, framework and management skills.
41+
42+
[^1]: https://www.wsj.com/articles/SB10001424053111903480904576512250915629460
43+
44+
[^2]: https://www.youtube.com/watch?v=x7ozaFbqg00
45+
46+
[^3]: http://www.oreilly.com/programming/free/getting-started-with-innersource.csp

introduction/scenarios.md

Lines changed: 140 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,140 @@
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[^1]. 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”[^2] 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 [^3] 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[^4] 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"[^5] 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+
[^1]: https://en.wikipedia.org/wiki/Omnichannel
133+
134+
[^2]: https://en.wikipedia.org/wiki/DevOps
135+
136+
[^3]: https://www.weforum.org/agenda/2016/11/70-of-employees-say-they-are-disengaged-at-work-heres-how-to-motivate-them/
137+
138+
[^4]: http://www.towerswatson.com/DownloadMedia.aspx?media=%7B1EBA6F1E-B1E7-4F0A-A9F7-D828C4D8B2AE%7D
139+
140+
[^5]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us

0 commit comments

Comments
 (0)