Your Open Source strategy sucks!

1. Your Open Source strategy sucks! (well,… probably mine stinks)

2. A word of caution

3. Who are you to say that? “I know nothing except the fact of my ignorance”. - Socrates

4. Agenda • Adopting Open Source • Traps and pitfalls • Open Source Software adoption check list • Open Source Software adoption strategy

5. Agenda • Adopting Open Source • Traps and pitfalls • Open Source Software adoption check list • Open Source Software adoption strategy

6. Adopting Open Source And getting the most out of it

7. The Open Source advantage • License cost • BORING!… • License management • Getting better • Software quality • Jury is still out on this • Lock-in avoidance • Starts getting interesting

8. It all boils down to…

9. Empowerment means: • Solution ownership • Data ownership • Supplier replaceability • Software life cycle management: • Updates • Patches • Decommissioning

10. Turning the tables • Revert (back to the roots) the supplier/customer relationship • Getting married every day: • Higher commitment from suppliers • Competition works throughout the cycle • Customer first (again)

11. Open Source based strategies

12. What’s a strategy, anyway? “What do you want to achieve or avoid? The answers to this question are objectives. How will you go about achieving your desired results? The answer to this you can call strategy.” - William E. Rothschild

13. Objectives? • Achieve: • A technical solution to a problem • A coherent infrastructure • Empowerment • Control • Ultimately, Return on Investment • Avoid: • Brick walls • Lock-in Open Source Software can help. A lot. But…

14. The need for a strategy • Download and run is short-sighted • Consider, at the very least: • Legal issues • Solution assessment (“will it work?”) • Risk management (“what if?”) • Configuration management • Life span • Decommissioning/migration

15. Legal issues • No license is equal • General issues: • License compatibility (e.g. BSD software using GPL libraries) • Oversight process within the project (e.g. IP issues) • Specific issues: • Simple internal use, no modification: relatively easy • Redistribution: might need to abide by the project decision

16. Solution assessment • Requirements fulfilment ratio • What can be done to reach 100%? • Compatibility: • Technical • Environmental • Cultural • Background • Established solution? • Proven track record? • Commercially supported? • Community assessment • Diverse participation? • Governance?

17. Risk management • Technical risks: • Software quality • Security • Scalability • Community risks: • Why is this software Open Source? • Will the project stay? • What if the community divides? • What if the project diverges?

18. Configuration management • Deployment is troublesome • How are configurations stored? • Accounting? • Upgrades? • Patches? • Continuity?

19. Life span • Solution scope • Maintainability over the years • Migration to different architectures • Environment health

20. Decommissioning • Eventually, the solution will be superseded • What happens to data?

21. Traps and pitfalls

22. Fake Open Source • A license is not enough • Proprietary solutions with open code • Tell-tale signs: • No community • “Enterprise” version with closed source functionality • Baitware: caveat emptor

23. Code dumps • Dead software • OSS as a last resort solution • Tell-tale signs: • No community • No development

24. Legal issue • Don’t snore just yet • IP matters • Licenses matter • Side effects of license mix matter

25. Open Source Software adoption check list

26. Ecosystem • Is your company ready for Open Source? • Management commitment • Cultural change • (some) DIY IT • If not: • Contact an Open Source vendor • Manage Open Source the traditional, proprietary way • Get only the technical benefits (still not bad)

27. Solution background • Project stability (easy questions) • How long has the project been around? • How many reference customers of your size has it got? • Are there books published? • Download statistics? • Commercial software? • Community (much more difficult) • How diverse (multivendor) is the community? • Democracy or oligarchy? • Governance rules?

28. Legal issues • Are/have been there IP issues? • Is there a process to ensure license compatibility within the project? • Is the license compatible with the intended usage? • Are you prepared for the worst case scenario?

29. Technical issues • Does it solve the problem in full? • If not, how can it be customized/extended/integrated? • Is technology compatible with your environment? • How is deployment managed? • How is configuration managed? • Does the solution support High Availability? • Can you ensure a business continuity plan?

30. Commercial issues • Can you easily get commercial support? • Do you have alternative support channels? • Does support come from professionals or companies? • Will your support channel take care of your customizations/integrations/extensions as well? • Can your support channel ensure that patches will be submitted and could be included in the mainstream distribution? • Can your support channel (co)drive the release process?

31. OSS adoption strategy

32. Strategy plan for a successful OSS adoption • Commit • OSS might not be for the faint of heart • Prepare • Get trained • Ensure bottom-up willingness to participate • Ensure top-down willingness to participate • Evaluate • Checklist homework • Plan • Adoption • Deployment • Support • Decommission

33. Plan B (works as well) • Approach OSS as if it was commercial software • Deal with vendors • Leverage the technology advantage • Consider a roadmap to the Real Thing

34. Questions?