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?