Open source software projects need to ensure that people are willing and able to engage with their software communities. Similarly, businesses seeking to adopt open source solutions need to be sure they can do so without exposing themselves to unmanageable risk. Evaluating technical risk of open source is often easier than it is with closed source, simply download the code and conduct and build a basic proof of concept. But dig a little deeper, there are many non-technical questions buried underneath, such as: •Will the project still be there in a year, five years, ten yeats, longer? •Can I influence the project to ensure it suite my needs? •Can I buy support if I need it? •What if the project leadership stop development tomorrow? •Will the license restrict my business model? •What are the main risks and how do I mitigate against them? •If I do bet my business on it what aspects of the project must I focus my attention on first? This session will introduce an approach to evaluating the maturity of the non-technical aspects of an open source software solutions. Using this evaluation we can clearly see any weak points in a projects development and governance processes. Once identified those weaknesses can be addressed or avoided as appropriate. Through a number of case studies we will demonstrate how this model assists in project planning and resource allocation when adopting open source solutions.

1. Managing project risk
when using open source
Ross Gardler
OpenDirective
@rgardler rgardler@opendirective.com

2. Software Failure
• Sainsbury write of $526M invested in supply-chain automation
• Hershey unable to fulfil $100M of orders due to failure of $112M IT
system
• 60,000 pensions and benefits claims unprocessed in UK due to IT
failure on a budget of £413M
• Sift (UK SME) wasted £1M on cancelled IT rewrite
Source: http://lessons-from-history.com/node/89

3. It should only cost 7p
• Proper
• Planning
• (and) Preparation
• Prevents
• Piss
• Poor
• Performance
Source: British Army

4. Ross Gardler
• Co-founder of OpenDirective
• Consultancy specialising in open innovation of software
• Open source developer since 1995
• Executive Vice President of The Apache Software Foundation
• Mentor to projects large and small
• in companies large and small

5. Managing risk
• Emphasis on MANAGING
• Need to:
1. Understand common risk factors
2. Evaluate candidates against those factors
3. Understand risk management strategies
4. Allocate project resources to manage risk
5. Repeat

6. Common Open Source Risk

7. Legal
• Does the licence allow you to…?
• Can the software be released under that license?
• Can you release your software under the chosen licence?
• Are there fees associated with the software?
• Are contribution terms acceptable?
• Can the software be bought and removed?

8. Standards
• Does the software play nicely with other software?
• Can you move away from the software?
• Are the standards used encumbered?
• Who owns and manages the standards?
• Can you influence the standards?

9. Knowledge
• Can your people work with the software?
• Can your people or sub-contractors adapt the software?
• Can you add to the knowledge?
• Is there a restricted group who control critical project information?
• Is there a paywall to critical information?

10. Governance
• Can the project pivot without your knowledge?
• Can you influence project strategy?
• Can your interests be blocked?
• Is the playing field level?
• Will your contributions be accepted?
• Will contributions be managed for the good of the project?

11. Market
• Is there (potentially) multiple suppliers?
• Can newcomers enter the market with new product/services?
• Does one supplier have an unfair competitive advantage?
• Do the majority of project committers work for a single company?
• Is there a supplier who understands your market?

12. Measuring risk

13. Apache project
• Labs
• High risk
• Incubator
• At your own risk
• Top level projects
• Managed risk
• Attic
• At your own risk

14. What does the incubator do?
• Community development
• Ensure the project is governed according to the Apache Way
• No BDs
• Clean IP
• Supportive and open community
• Etc.

15. What if it’s not an Apache project?
• Openness Rating
• Evaluates development model
• Identifies areas of potential risk
• Plan for risk management
• One part of a larger evaluation process
• Software Sustainability Maturity Model
• In addition to development model evaluation
• Fitness
• Reusability
• Capability

16. Evaluating Openness
More open projects = more flexibility for users

17. Conducting an openness evaluation
• Series of questions in five categories
• License
• Standards
• Knowledge
• Governance
• Market
• Decide on acceptable risk profile
• Weight categories of evaluation
• Weight individual questions

18. Result is a “score”
• Quantitative evaluation
• numbers are indicators only
• Need to ensure consistency in the evaluation responses
• Low scores indicate areas of risk
• Compare risk across different alternatives
• Invest resources to mitigate risk?

19. Layered evaluation
SSMM • Maturity of project
Openness
• Freedom to engage
Rating
Openness
• Areas in need
Categories
Specific
• Actions
Questions

20. The Categories

21. License
• What kind of license?
• IP due diligence
• Traceability

22. Standards
• Standards compliance
• Openness of standards used
• Royalty or Patent requirements
• Recognised governance body

23. Knowledge
• How we got here
• Where we are going
• User support
• Developer support

24. Governance
• Structure
• Succession
• Codes of behaviour
• Transparency
• Accountability
• Who can participate
• Roles of project participants

25. Market
• Money makes the world go round
• Money pays for developers
• Money raises awareness
• Money provides better user support
• Is there a healthy commercial ecosystem?

26. Can I use it?

27. Can I use it?
• In constant development
• Use it and help us improve it
• Open Content (CC-BY-SA)
• Mail me at rgardler@opendirective.org for a copy
• The sales pitch
• 1, 2 and 4 day training
• Consultancy services

28. Discussion
• Ross Gardler
• @rgardler
• rgardler@opendirective.com