<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>
Technical Guidelines
-
Understand the way OSS is developed
-
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.
-
Use the flexibility of OSS to create local adaptations
-
In selecting packages, always favor stability over functionality
-
Design the workflow support infrastructure to reduce the number of “impedance mismatches”
-
Introduce a trouble ticket system
-
Compile and update a detailed migration workbook
Migration workbook Standard engineering practice.
Social Guidelines
-
Provide background information on OSS
-
Don’t force the change on the users, provide explanations
-
Use the migration as an occasion to improve users skill
-
Make I easy to learn and experiment
Business Models
-
Externally funded ventures
-
Public funding
-
`Needed improvement’ funding
-
Indirect funding
-
Internally funded or revenue based
-
`Best knowledge here without constraints
-
`Best knowledge here’ with constraints
-
`Special’ licenses
-
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
-
Leave a Reply