First draft of goals outline for FOSS 101.

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

1 files changed, 138 insertions, 0 deletions

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.