Why is Open Source so Good: Thirty Years of Lessons Learned
•
2 likes•1,627 views
One would think that traditional corporate software development, where developers are closely supervised, and directed by plans and schedules, would result in the creation of more consistent and higher quality software than open source development, where developers have significant freedom to choose the goals and pace of projects they choose to work on. And yet, open source software is often of excellent quality, and can transform existing industries and business models. When does the open source "magic" happen, and when does it now? We can learn some lessons from looking back over several open source projects and communities, and see how those lessons have been applied to the current OpenStack project and community.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Why is Open Source so Good: Thirty Years of Lessons Learned
Similar to Why is Open Source so Good: Thirty Years of Lessons Learned (20)
Recently uploaded
Recently uploaded (20)
Why is Open Source so Good: Thirty Years of Lessons Learned
- 1. Why is Open Source so Good? Thirty Years of Lessons Learned Mark Atwood mark.atwood@hp.com Twitter: fallenpegasus © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 2. Big Disclaimer © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 3. Why is Open Source so good? © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 4. Why is Closed Software so bad? © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 5. We know what makes good software! • Decoupled design • Simple orthogonal interfaces • Iterative Development • Code Review • Testing • Happy Programmers 5 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 6. Closed Source Process • “Business Needs” drive development • Meaningless deadlines • Anti-pattern architecture • Crunch time, crush passion • Difficult process • Yet too easy to add code • Technical debt is always hard to pay off 6 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 7. Open Source at Different Scales © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 8. One Programmer • “scratch the itch” • Going to make it work • Won’t make it too complex • Will last as long as it’s useful 8 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 9. One person, plus contributors • The one will code review everything • The one is not going to break it • The one can “pass the torch” • Contributors cause “stone soup” 9 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 10. Small Team • Will write what makes them all happy • Can’t force work they don’t want 10 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 11. Large Team, on large projects • Can Open Source possibly work? • Lots of failures • Lots of very painful successes • Lots of lessons learned, if we look for them 11 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 12. Big Disclaimer © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 13. GCC & Gnu BinUtils • Tightly coupled team • Tightly coupled design • Resistant to outside contributions 13 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 14. Conway’s Law • “The organization of the software and the organization of the software team will be congruent” • Loosely coupled teams encourages loosely coupled software. 14 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 15. Linux • Really big “one, with contributors” • We got very lucky (can’t manufacture a Linus as needed) • We discovered “Linus’s Law” • We discovered DVCS 15 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 16. Java & JCP • Developed “corporate style” • Unhappy developers • Dominated by one company • Closed testing, QA, certification 16 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 17. ASF Java • “Deep Rich APIs” • APIs are coupled to implementation • Huge pile of churned out & aging “donated” code • Uninvolved “maintainers” • Did discover that big companies can collaborate 17 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 18. MySQL • Dominated by one company • Tightly coupled design • Features driven by Marketing goals • Feature Release over Time Release • Hard to build • Resistant to outside contributions 18 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 19. Lessons we should learn • Easy to get involved • Easy to contribute • Easy to use dev tooling • Loose coupling • Code Review is critical • Tooling that encourages collaboration • Human communication 19 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 20. OpenStack • Not controlled by one company • Business goals cannot override the process • Code review is central • APIs are HTTP REST WSGI • Time Based Release • No “commit bit” 20 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 21. Open Source • Apache 2.0 License • Public DVCS (Git) • Open Source friendly language (Python) • Open Source friendly framwork (HTTP, REST, WSGI, ) 21 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 22. Open Design • Good ideas are welcome to try • Service API oriented • Necessary decisions by PTL & TC 22 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 23. Open Development • DVCS • Public Code Review • Infrastructure is Open Source • Anyone can run dev 23 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 24. Open Participation • Egalitarian Process • Open Design Summit, in person • Open Meetings, in IRC • Technical Leaders are chosing by the technical contributors • Representation on the governance 24 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 25. Gated Trunk • Ensures code quality • Always start from working code • Bad code does not land • Same for everyone • Machines don’t flame on the list 25 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 26. Open Sources works when • Decoupled design • Code Review • Easy participation • Avoid corporate anti-patterns 26 © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
- 27. Thank you © Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.