From a4f67694f4a9b4c29b7dea24e4af5ac64a016517 Mon Sep 17 00:00:00 2001 From: Sarah Sharp Date: Thu, 24 Mar 2016 21:42:33 -0700 Subject: First draft of goals outline for FOSS 101. Signed-off-by: Sarah Sharp --- open-source-101.txt | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 open-source-101.txt diff --git a/open-source-101.txt b/open-source-101.txt new file mode 100644 index 0000000..e230b56 --- /dev/null +++ b/open-source-101.txt @@ -0,0 +1,138 @@ +The target for this training is organizations that know nothing about open +source, but are either: + +1. Forced by internal politics or outside forces to participate in open source. +2. Show an interest or willingness to change, but are clueless on what to do. + +There are three separate target audiences: + - VPs, executives, and upper management (30 minutes) + - 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. + - 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. + - 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". + +4. Your corporate value add is in hardware IP, not software. + - No one pays for operating system software, only services. + - "Vendor lock-in" via software is not a long-term strategy. + - 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). + + +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) + - more maintainable architecture + - community fixes breakage + - eliminating technical debt + - 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. + +3. Different flow for technical collaboration. + +4. Trust your engineers + - 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. -- cgit v1.2.3