Your OSS Strategy Sucks
A light-hearted look at using Open Source in an insitutional context. From Andrew Savory of Luminas Ltd.
Lecture Notes follow
--------------------------
I'm going to start by betting that the question 'what is a strategy' will not be adequately answered :-) . [to be fair there's a more of less adequate quote that's just been put up about it]
Stuff to think about : Costs, Lockin, Empowerment, Solution ownership, Data ownership, Maintenance...
Open source as a spur to competition that makes the software market competitive through the whole cycle. ..
Traps and pitfalls
---------------------
Fake open source - the license is not enough. Look for a community, (no community - not open source???)
Is there an enterprise version (and fee)
Code dumps - opensourcing dead projects
Legal issues - are the licenses appropriate
The need for strategy
--------------------------
Work through a checklist on...
Environment - is the organisation ready for it? Management committment, cultural change, skills to do DIY IT.
Solution background - health of the project, size of the community, direction
Project Stability - age, reference customers, books / documentation - books are a sign that a significant number of people care, download statistics, commercial extentions?,
Community How is it run, governed etc. How big is the community, how diverse is the community, what do the community think they're doing?
Legal How well are IP issues managed on this project, are they keeping track of the licenses for third party products, does the license allow the intended uses?
Technical Issues Is it all compatible, how easy is it to deploy, configure, manage etc. Can you guarantee business continuity.
Risk Management Regarding the quality of the code and the community in particular.
Support Is support available, and who from? Can the support do the tricky stuff (integration, extension etc) will your support source be able to feed back into the community?
Developing a plan for overcoming this lot...
1. Commit (from management and those who will be working with it)
2. Expectations (no guarantees that the community will care about your specific problems)
3. Get ready (training plan etc. Make people willing to use the new tools)
4. Evaluate (which of the available solutions are you going for)
5. Plan (Deployment, support, decommissioning)
6. Plan B