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.

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.