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 - "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.