Managers/PMs: add notes on approach.

Brainstorm concerns about open source, and why corporations would participate
in open source. Key take-aways are differences in open source vs closed source
workflow models, and the fact that open source scales better.

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

1 files changed, 119 insertions, 10 deletions

diff --git a/open-source-101-pms.txt b/open-source-101-pms.txt
index 0ff4bac..2e48447 100644
--- a/open-source-101-pms.txt
+++ b/open-source-101-pms.txt
@@ -1,13 +1,28 @@
-Approach:
+Two key slides to take away
+---------------------------
+
+Open source process slides.
+
+Scaling slides.
+
+
+Approach
+--------
 
 20 minutes:
 
-Start by 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).
+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:
 
@@ -21,11 +36,13 @@ Brainstorm with managers. Identify key managers, engineers, and architects to be
 agents of change within the organization.
 
 
-1. FOSS quality
 
-1a. Security Myths:
+Possible concerns about open source
+-----------------------------------
+
+1. Security
 
-Anyone can see open source code, so it's easier to create security exploits.
+"Anyone can see the code and exploit security venerabilities."
 
 CVE data shows Microsoft products have more critical venerabilities than Linux
 products:
@@ -36,6 +53,98 @@ http://www.cvedetails.com/cvss-score-charts.php?fromform=1&vendor_id=26&product_
 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