Flesh out exec section.

Will need to customize each message to execs, depending on what they need to
hear.

Signed-off-by: Sarah Sharp <sarah@thesharps.us>

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