Why is Open Source so Good: Thirty Years of Lessons Learned
2 likes1,628 views
The document discusses the advantages of open source software compared to closed source, emphasizing the importance of decoupled design, iterative development, and community collaboration. It highlights lessons learned from various projects, such as Linux and OpenStack, showcasing how open source fosters easier participation and better code quality. Key principles include effective code review, community involvement, and avoiding corporate anti-patterns.
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 [email protected] 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.