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
|
Two key slides to take away
---------------------------
Open source process slides.
Scaling slides.
Approach
--------
20 minutes:
Start by asking them to define open source. Don't muddle their brain with
license differences (save those details for the engineers), or "free software"
vs "open source software". Want to talk about the different models of open
source collaboration (freely available & corporate controlled to open
collaboration and community controlled).
Asking for their concerns about open source. Treat this as a brainstorming
session, and write down their concerns on a whiteboard (or similar). Do
a similar brainstorming session for why companies choose to participate in open
source. This allows us to gauge the knowledge and concerns of the room, and make
people feel like they're being listened to. Tailor content based on that session
(with lots of backup slides).
10 minutes:
Level set on open source process vs. closed source top-down software
development.
30 minutes:
Discuss cultural changes that need to be made, and how to approach them.
Brainstorm with managers. Identify key managers, engineers, and architects to be
agents of change within the organization.
Possible concerns about open source
-----------------------------------
1. Security
"Anyone can see the code and exploit security venerabilities."
CVE data shows Microsoft products have more critical venerabilities than Linux
products:
http://www.cvedetails.com/cvss-score-charts.php?fromform=1&vendor_id=33&product_id=&startdate=2011-04-04&enddate=2016-04-04
http://www.cvedetails.com/cvss-score-charts.php?fromform=1&vendor_id=26&product_id=&startdate=2011-04-04&enddate=2016-04-04
Hiding code does not make a product safer.
2. Exposing future IP
"Our competitors will know about our new software/hardware features."
Talk about momentum - can competitors leverage your code that fast? Could they
build the same features into their hardware in a short amount of time?
Downside to waiting too long to get code upstream - many Linux distributions
have a long time between releases (6-12 months), and code must be upstream 1-8
weeks before the code freeze deadline.
Impact for HW vendors: Your customers don't have wizbang new feature at product
launch, you get bad performance reviews on sites like ZDNet, Engadget, Phoronix,
Tom's Hardware, etc.
Impact for SW vendors: Your customers have to go through the pain of compiling
and installing software.
Vocabulary: upstream, OEM, Linux distribution
3. Anyone can contribute
"What if someone is deliberately putting bad code in?"
Maintainership model discourages this. Drive by code drops are viewed with
suspicion.
"But our competitors could be working on the same project!"
Yes. Shared code causes all boats to rise. You must be able to learn to
collaborate with competitors, students, hobbyists, government contractors, and
everyone. "Meritocracy" - the "best" code often wins on technical merit
- although it's often the code from the person who has the most respect from the
community.
4. Open source will slow us down.
Short term: yes. Long term: more maintainable code, easier to scale.
Leads into the maintainability and scale discussion.
5. My engineers have to work in the public?
Yes.
Downside to polishing code too much: May not be solving the right problem. May
need to rearchitect the code multiple times, causing you to miss your deadline.
See http://airlied.livejournal.com/80112.html
This leads into the different process for open source vs closed source.
Benefits of open source
-----------------------
1. Allows companies to scale to multiple customers.
Many companies only have resources to deploy their software across a few
platforms, and test on a few different software environments. By having an open
source code base, you allow customers to quickly fix issues. Open source
eliminates overhead for reporting issues, allowing direct engineer-to-engineer
communication.
(Pull in info from exec slides on latest update trends from Microsoft, Apple,
and Google.)
2. Getting code upstream cuts down long-term costs of updating software.
The community will update it for you, if they break APIs (and they will).
3. Long-standing contributors influence open source direction
Your competitors will be contributing to open source. The maintainers always try
to be vendor-neutral, but they will often accept code from long-standing
contributors will less fuss than from newcomers. That means your competitors who
integrate themselves into open source communities have an advantage to getting
in code that supports the new features they need. It is to your advantage to
participate and have your engineers build up a reputation in the community.
Misc
----
1a. Maintainability
Car manufacturers get most of their software stack from third-party vendors who
put all the security liability on the manufacturers. There is no incentive to
update or keep their software secure. Since, car manufacturers have such a long
ramp-up time for safety approval and they have to maintain the car software
stack for 7-10 years, they are turning to open source.
http://embedded-computing.com/articles/the-car-its-about-integration/
"What's not so obvious is that as complexity grows, the ability to innovate
shrinks. Why? Because if more and more of your development time and resources
are spent managing development options, associated requirements, and integration
testing, less time, money, expertise, and creative energy are available for
invention."
"Open source maintainership is for life."
5. Cost of technical debt
Talk dollars
Android devices vs kernel versions and dates (as of March 31, 2016)
Android Version |API Level |Linux Kernel in AOSP |% of Android devices |Kernel release date |Latest stable version |# of patches to port
--------------------------------------------------------------------------------------------------------------------------------------------
1.5 Cupcake |3 |2.6.27 | | | |
1.6 Donut |4 |2.6.29 | | | |
2.0/1 Eclair |5-7 |2.6.29 | | | |
2.2.x Froyo |8 |2.6.32 | | | |
2.3.x Gingerbread |9, 10 |2.6.35 | | | |
3.x.x Honeycomb |11-13 |2.6.36 | | | |
4.0.x Ice Cream San|14, 15 |3.0.1 | | | |
4.1.x Jelly Bean |16 |3.0.31 | 8.1% |2012 | |
4.2.x Jelly Bean |17 |3.4.0 | 11.0% |2012 | |
4.3 Jelly Bean |18 |3.4.39 | 3.2% |2013 | |
4.4 Kit Kat |19, 20 |3.10 | 34.3% |2013 | |
5.x Lollipop |21, 22 |3.16.1 | 36.1% |2014 | |
6.0 Marshmallow |23 |3.18.10 | 2.3% |2015 | |
sources:
http://android.stackexchange.com/questions/51651/which-android-runs-which-linux-kernel
http://developer.android.com/about/dashboards/index.html
QUESTION: Do phone manufacturers choose to use an older version of AOSP so they
can run on cheaper hardware? Or is the above chart just showing the aging of
older phones?
|
