Me and My World

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Technical Guidelines

1. Understand the way OSS is developed

2. Create a complete survey of software and hardware that will be affected by the migration, and what functionality the company is looking for .

   Make sure you check every software installed. Is it open or closed communication protocols. Find out the data format.

3. Use the flexibility of OSS to create local adaptations

4. In selecting packages, always favor stability over functionality

5. Design the workflow support infrastructure to reduce the number of “impedance mismatches”

6. Introduce a trouble ticket system

7. Compile and update a detailed migration workbook

   Migration workbook Standard engineering practice.

Social Guidelines

1. Provide background information on OSS

2. Don’t force the change on the users, provide explanations

3. Use the migration as an occasion to improve users skill

4. Make I easy to learn and experiment

Business Models

1. Externally funded ventures

2. Public funding

3. `Needed improvement’ funding

4. Indirect funding

5. Internally funded or revenue based

6. `Best knowledge here without constraints

7. `Best knowledge here’ with constraints

8. `Special’ licenses

9. Unfunded developments

The 6 main clusters identified are:

• Dual licensing: the same software code distributed under the GPL[11] and a commercial license.

• Split OSS/commercial products: based on open source license but with proprietary plugins. Example: Zimbra

• Badgeware: the software is free but u must acknowledge the author

• Product specialists

• Platform providers: company who don’t create something, but they pack it with their software package