Choosing The Right Open Source Project Scott Leslie, Edutools.info SFU, July 28, 2005

You are here? Outer Hebrides?

Development/Acquisition Evolution BUY SHARE BUILD VS. BUY VS.

Suitability = Maturity vs. Capability Organization’s Capability for Development ‘ Maturity’ of Project / Community ‘ Freeloading’ Very Mature Immature Low High Project Originator Real Risk of Failure Low Risk Decisions OS ‘Sweet Spot’ What makes OS communities thrive

Suitability = Maturity vs. Capability Organization’s Capability for Development ‘ Maturity’ of Project / Community Very Mature Immature Low High Real Risk of Failure #1 “ Low Risk Choice” #2 “ Adoption, not adaptation” #3 “ Major Boost” #4 “ Good Luck!”

Capability Profile 1 – “R1 Uni” No desire to spin off derivative work Desire to commercialize derivative or related works Unknown Related Institutional Networks and affiliations Have been done this road before Past Experience with Open Source projects History of project-based work, distributed, multi-unit work teams Preferred Project Management Style Have been done this road before; can keep existing CMS in place Institutional Tolerance for Beta Products Desire to replace existing CMS Existing framework, architecture or e-learning infrastructure Some, but could use more formal environment Existing Software Development Process and Environment Risk area long term Ongoing Developer Resources Good but not great; the more they can bootstrap, the better Project-based Developer Resources

Capability Profile 2 – “CommCollege” No desire to spin off derivative work Desire to commercialize derivative or related works Entire State System Related Institutional Networks and affiliations Are intrigued by the prospect but no real experience Past Experience with Open Source projects Not strong on project-based work Preferred Project Management Style Used to COTS Institutional Tolerance for Beta Products High risk as they require something soon to come out of this process Existing framework, architecture or e-learning infrastructure Problematic for engaging with other organizations & contributing back Existing Software Development Process and Environment Could use more Ongoing Developer Resources Could use more Project-based Developer Resources

OS Software Maturity Profile 1 GPL Licensing Model Initial developers still control process & comm Governance Model None 3rd party support providers / vendors Good but could be improved End-user documentation / support community Informal at best Explicit and implicit developer education and socialization paths Very active Developer documentation / support community LAMP, so few concerns Dependencies/ Standards Very active Activity within the development community, forums and mailing lists Some Explicit OS Development Roles 8 / 1 main, many peripheral # developers/Organizations Fixes bundled as part of quarterly release cycle Project Reputation (for stability, rapidity of bug fixes) Over 10 major releases Number of releases

OS Software Maturity Profile 1 GPL Licensing Model Initial developers still control process & comm Governance Model None 3rd party support providers / vendors Not much End-user documentation / support community Informal , if at all Explicit and implicit developer education and socialization paths Not much Developer documentation / support community All OS, so few concerns Dependencies/ Standards No aparent developer forums Activity within the development community, forums and mailing lists Not evident Explicit OS Development Roles 3/ 1 main # developers/Organizations No apparent schedule or roadmap Project Reputation (for stability, rapidity of bug fixes) Under 3 releases Number of releases