From afa2f24defc64ddbc84ae41fcb351251d93b4251 Mon Sep 17 00:00:00 2001 From: Sarah Sharp Date: Mon, 18 Apr 2016 09:20:05 -0700 Subject: 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 --- open-source-101-pms.txt | 129 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file 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 -- cgit v1.2.3