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.