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

A word of caution

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

Agenda  Adopting Open Source  Traps and pitfalls  Open Source Software adoption check list  Open Source Software adoption strategy

Agenda  Adopting Open Source  Traps and pitfalls  Open Source Software adoption check list  Open Source Software adoption strategy

Adopting Open Source And getting the most out of it

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

It all boils down to…

Empowerment means:  Solution ownership  Data ownership  Supplier replaceability  Software life cycle management: Updates Patches Decommissioning

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)

Open Source based strategies

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

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…

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

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

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?

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?

Configuration management  Deployment is troublesome How are configurations stored? Accounting? Upgrades? Patches? Continuity?

Life span  Solution scope  Maintainability over the years  Migration to different architectures  Environment health

Decommissioning  Eventually, the solution will be superseded  What happens to data?

Traps and pitfalls

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

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

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

Open Source Software adoption check list

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)

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?

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?

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?

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?

OSS adoption strategy

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

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

Questions?