diff options
Diffstat (limited to 'open-source-101.txt')
| -rw-r--r-- | open-source-101.txt | 45 |
1 files changed, 36 insertions, 9 deletions
diff --git a/open-source-101.txt b/open-source-101.txt index 773d114..482a626 100644 --- a/open-source-101.txt +++ b/open-source-101.txt @@ -9,7 +9,8 @@ Motivation for open source development may include: 3. Transitioning an existing closed-source project to open source. There are three separate target audiences: - - VPs, executives, and upper management (30 minutes) + - 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) @@ -19,21 +20,38 @@ Upper management Needs to understand: ==================== -1. Why open source is good for business. +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. Established open source projects have momentum. - - Customers stick with less performant software because they have the - flexibility to make their own changes. - - Customers develop a trust relationship with established maintainers. +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). @@ -41,11 +59,20 @@ Needs to understand: 3. Corporate power means nothing to open source communities. "Big" corporations don't automatically "win". -4. Your corporate value add is in hardware IP, not software. - - No one pays for operating system software, only services. + - 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 for operating system software. - "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. - - Leverage shared code 5. High-level overviews of what changes are necessary (cultural, infrastructure, management, planning, engineering collaboration, etc). |