1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
The target for this training is organizations that are interested in having
their employees participate in open source, but have traditionally focused on
creating closed-source products.
Motivation for open source development may include:
1. Participating in an existing open source project that is business critical.
2. Creating a new open source project from scratch.
3. Transitioning an existing closed-source project to open source.
There are three separate target audiences:
- VPs, executives, and upper management (5 minute pitch, 25 minutes for
questions)
- People managers and project managers (1 hour)
- Engineers (2-3 hours, depending on experience using open source or Linux)
Upper management
----------------
Needs to understand:
====================
1. Why open source is good for business. Reasons should be tailored to the
immediate and long-term business needs of the executives, but may include:
- better customer service response times
- scale to meet the long-tail of customer needs
- open up new business opportunities by allowing customer research
- true open source (vs available source) allows customers to fix issues
- customers may even submit features for you (but don't count it)
2. If execs are planning to launch a new open source project, or shift a
closed-source project to open source, an evaluation of the current open
source project landscape needs to be done. The execs need to understand that
established open source projects have momentum.
- Customers may stick with less performant software because they have the
flexibility to make their own changes to the software they currently use
and build upon. currently using. Switching stacks brings additional risk
that the maintainers of your new project will ignore their bug reports,
refuse to accept new features, and generally slow down the process of
ramping up development of their next project.
- Customers develop a trust relationship with established maintainers. Their
engineers have working relationships with maintainers and developers in the
open source community, and may be able to get them to respond faster.
Response time in a new project is not guarateed.
- Customers consuming open source products will evaluate your product on
technical merit, and no amount of marketing is going to change that.
- You cannot gestate a baby in 1 month by applying 9 mothers. You cannot
build an open source community over night.
- Open source community building takes time and special effort
(documentation, mentoring, trust building, conference presentations,
technical demos, community managers, passion from hackers).
3. Corporate power means nothing to open source communities. "Big" corporations
don't automatically "win".
- Many different companies may contribute to the same project.
- Often times, engineers from different companies (or volunteers working on
software as a hobby) will need to work together on a solution.
- Shared code is leveraged by competitors and partners alike.
4. Your corporate value add is in services and hardware IP, not software.
- No one pays much for operating system software and customers are coming to
expect free updates. Apple devices are a rare exception. Apple started
offering upgrades in 2014 that cost around $69 to upgrade an older system
from Snow Leopard -> Lion. Microsoft announced Windows 10 would receive
free upgrades for "the supported lifetime of the device" (unclear what
exactly that means). Google Chromebooks have five years of free upgrades.
Android Google devices receive updates for an average of 21 months (nearly
two years).
sources:
http://www.androidpolice.com/2015/09/17/software-updates-a-visual-comparison-of-support-lifetimes-for-ios-vs-nexus-devices/
http://arstechnica.com/gadgets/2015/01/windows-10-free-for-all-windows-8-1-and-windows-7-users-for-first-year/
https://blogs.windows.com/windowsexperience/2015/01/21/the-next-generation-of-windows-windows-10/
Number of PCs shipped in the last five years:
2011: 92.2 million
2012: 90.3 million
2013: 82.6 million
2014: 83.7 million
2015: 73.7 million
Total: 422.5 million units in the last five years - all could get upgraded
to Windows 10, and need continual support for upgrades
http://www.gartner.com/newsroom/id/1893523
http://www.gartner.com/newsroom/id/2301715
http://www.gartner.com/newsroom/id/2647517
http://www.gartner.com/newsroom/id/2960125
http://www.gartner.com/newsroom/id/3146617
Number of Chromebooks shipped:
2013: 2.9 million
2014: 5.7 million
2015: ?
http://www.gartner.com/newsroom/id/2819917
http://www.gartner.com/newsroom/id/3058517
- "Vendor lock-in" via software is not a long-term strategy.
- Hackers will dissect and replicate your closed-source software. (Note --
most execs will not understand decompiling, reverse engineering, watching
PCI register reads, running software in a VM, using a debugger or
hardware simulator to change memory, sniffing network traffic, etc, so
keep this point simple.)
- You can't add "special sauce" or lie about performance in open source.
5. High-level overviews of what changes are necessary (cultural,
infrastructure, management, planning, engineering collaboration, etc).
What change needs to happen:
============================
1. Buy-in for the cultural change that needs to happen.
2. Top level drive towards open source and upstream strategies.
3. Shift away from "protecting" software IP to opening it up.
4. Understanding that sustainable open source takes time.
People managers / Project managers
----------------------------------
Needs to understand:
====================
1. Why open source makes a better quality product.
- security (dispel myths)
- community fixes breakage
- eliminating technical debt
- more maintainable architecture
- engineers have passion for meeting the end customer's needs; it's not just
a job.
2. Your corporate timeline means nothing to open source communities.
- Your tests need to be public if you're accepting open source contributions.
3. Different flow for technical collaboration.
4. Trust your engineers
- Open source social capital
- Engineers rule in open source.
- Maintainership is for life.
- Open source engineers are not interchangeable parts.
5. Why technical debt in FOSS is bad.
What change needs to happen
===========================
1. Buy-in for an "open source" timeline with wiggle room.
- Regressions are not tolerated, even for shiny wiz-bang new feature.
2. Help transition engineers to an open source collaboration model.
- Encourage engineer-to-engineer collaboration and direction setting.
- Don't micro-manage bug tracking, and don't ask for frequent feature
progress updates.
- Encourage engineers to release early, release often.
- Allow engineers space and time to make mistakes and learn.
3. Allow engineers to develop expertise.
4. Protect your engineers.
- Fight frequent changes in direction.
- Eliminate "fire fighting".
- Push back on "check mark" requirements that don't make sense for the
customer.
Engineers
---------
Needs to understand
===================
1. Why open source encourages creativity and collaboration.
2. Open source developers are working for the end customer, to improve their
world. It's a long term career, and they know they can switch companies at
any time. Therefore, open source developers must show no preference towards
any partner or any one corporation (even their own).
3. Years of experience mean nothing to open source communities.
4. Technical "meritocracy" by proving yourself to the community.
5. Release early, release often. Design discussions are different.
6. Code rules because there is no documentation and the tools suck.
What change needs to happen
===========================
1. Set your ego aside, do small tasks, and prepare to be taught by sensei.
2. You gain respect by showing a willingness to learn, and initiative on research
and change.
3. Engineers need to take initiative and not wait to be handed small tasks.
4. Response time to feedback must decrease dramatically.
5. Engineers must participate in open source community channels.
|
