Succeeding at Open Source

As presented at DevLink 2014

Transcript

1. H O W T O S U C C E E D AT O P E N S O U R C E G L E N C A M P B E L L All photographs ©2014 Glen Campbell Hot start ! I have been working WITH open-source software since the early 1990's (for example, with Perl and later with PHP and FreeBSD). I was the OWNER of an open-source package called Siteframe that I released in the early 2000's. Since then, I've CONTRIBUTED to various open-source projects, and I've watched with interest its growth over time. I've also seen the PUNDITs complain about it throughout that whole period. ! So, this session is mostly some observations from my personal experience about what works and what doesn't work when you're involved with open- source. ! A lot of this is common sense and is pretty self-evident, but I think it bears repeating in a consolidated manner.
2. W H AT I S O P E N - S O U R C E S O F T WA R E ( O S S ) ? I always like to define my terms. Many people have a relatively vague understanding of "open-source." And, in fact, the phrase is used in many different senses by different people. ! Linux is open-source, but contributions are controlled by Linus Torvalds and a couple of deputies. Android is open-source, but outsiders cannot contribute. OpenStack allows anyone to contribute, but is run by a foundation that accepts money from other businesses. ! Generally, however, open-source software is released under an open-source license...
3. O P E N S O U R C E . O R G • free distribution • source code • derived works • integrity of the author's source code • no discrimination against people and groups • no discrimination against fields of endeavor • distribution of license • license must not be specific to a product • license must not restrict other software • license must be technology-neutral This is the "official" definition of open-source software. Note that these are only the main headings; there's a lot more detail at opensource.org.
4. P O P U L A R O S S L I C E N S E S • Apache License 2.0 • BSD 3-Clause "New" or "Revised" license • BSD 2-Clause "Simplified" or "FreeBSD" license • GNU General Public License (GPL) • GNU Library or "Lesser" General Public License (LGPL) • MIT license • Mozilla Public License 2.0 • Common Development and Distribution License • Eclipse Public License Technically, any software is open-source if it is released under one of these (or other approved) licenses.
5. H O W B U S I N E S S E S S E E O P E N - S O U R C E • FREE$$$$ Seriously, there are a ton of businesses that use open-source simply because it doesn't cost anything. ! The problem, of course, is that there ARE costs associated with open-source, though they're often not fully understood.
6. O S S A D VA N TA G E S • Low-cost • Transparent • Maintained • Community • Shiny These are some of the commonly-perceived benefits of using open-source software. As is usual for gross generalizations, they are true but on a sliding scale (your mileage may vary)
7. O S S P R O B L E M S • Goals of OSS do not sync with business • Slow development • Missing features • Poorly supported • No SLAs or liability • Manual integration The same caveat holds for these: they are mostly true, for a variable value of "true."
8. O P E N - S O U R C E R E L AT I O N S H I P S • User • Contributor • Owner • Pundit When we talk about open-source software, there are a number of relationships that you can have. ! The first is as a USER; anyone who's installed their own copy of WordPress is an open-source user. You're simply the consumer of open-source code. ! The next is as a CONTRIBUTOR; not only do you use the software, but you also submit pull requests, patches, or file bugs or issues against it. You may even write requirements or work on testing. It some smaller or larger way, you're helping to make the OSS better. ! You can also be an OWNER. This is where you create something and release it under an open-source license. Unlike a regular contributor, you have further super-powers such as owning the Github repository. In 2001, I released Siteframe, an early "Web 2.0" framework, as an open-source project. ! Finally, I'll mention the PUNDITs. These are the trolls who loiter around any open-source project; they continually point out problems without offering solutions. ! We'll cover each of these roles in more detail....
9. U S E R S B U I L D I N G W I T H O P E N - S O U R C E S O F T WA R E
10. O S S U S E R S G E T • Existing software at no cost, little effort • Sometimes passionate community to support it • Variable-quality software • Documentation ranging from poor to brilliant
11. O S S U S E R S A L S O H U R T • No guarantees of support • No liability or SLAs • No commitment to add features or fix bugs • No help with integration
12. M A N A G I N G P R O J E C T S T H AT U S E O S S • Keep in touch with the community: email, IRC, StackOverflow • Thoroughly test new releases; don't skip • Define an integration plan and actively test it • File bug reports with the OSS project • Show your appreciation • Be flexible on schedules
13. D O N ' T • belittle or berate the community, especially publicly • complain without offering a solution • misinterpret a bad implementation with evil intent
14. C O N T R I B U T O R S G I V I N G B A C K T O T H E O S S C O M M U N I T Y
15. C O N T R I B U T O R S G E T • Ability to add features and fix bugs • Influence and guidance in the community • Advance notice of changes • Support for integration (by sharing with community) • Better alignment between business and OSS
16. C O N T R I B U T O R S F E E L PA I N • Release schedules are out of direct control • Business cannot trump the OSS community • Other contributors can alter features • BDFL may not want to help
17. M A N A G I N G O S S C O N T R I B U T O R S • Commit to supporting upstream before the business • Track critical features or fixes and prioritize work on them • Understand and document dependencies • Commit to testing & docs as well as development • Be flexible on schedules
18. D O N ' T • commit to things you can't deliver • be publicly critical of them • engage the trolls • go dark and silent
19. O S S O W N E R S C R E A T I N G F O R C O M M U N I T Y U S E
20. O S S O W N E R S G E T • Karma • Better control over releases, features, bug fixes • Clear product roadmap • Self-defined integration, SLAs, liability
21. T H E D O W N S I D E O F O S S O W N E R S H I P • Karma • Responsibility to the OSS community • Bad decisions can ruin a company's reputation • Security issues
22. O W N I N G A N O S S P R O J E C T • Be willing to listen to the community • Accept feedback and pull requests with enthusiasm and candor • Treat contributors equally • Don't be the BDFL from hell • Provide security testing and oversight
23. D O N ' T • play favorites • push people unnecessarily • forget that other contributors are voluntarily helping you • be an asshole
24. O S S P U N D I T S M O C K I N G T H E H A N D T H A T F E E D S Y O U
25. Y O U ' R E K I D D I N G , R I G H T ? • Unfortunately, no • There are people who will use OSS to stifle competition • Enough professional whining can damage a project • Be aware that they exist and they CAN hurt • Don't simply ignore them
26. M A N A G I N G O S S B U T M Y E M P L O Y E E S D O N ' T W O R K F O R M E ! The fact of the matter is, some of the most important contributors to your software do not work for you. How can you incentivize them and keep them motivated?
27. • Communication is key • Incentives: gittip, gifts, thank-you cards • Find out what motivates them • Recognition is important: social media shout-outs, blog posts, email to their boss • Hire them
28. S E T E X P E C TAT I O N S • Coding standards • Test requirements, both unit- and integration-level • Documentation! • Example code • Deadlines are good, but hard to enforce
29. C E L E B R AT E ! • Throw a party • Host a conference • Recognize contributions • Measure success
30. G I V E B A C K PA Y I T F O R WA R D
31. • Let your developers support other OSS projects • Encourage experimentation and "playing around" (aka "side projects") • Experiment with new tools and technologies • Push them into submitting conference talks • Google "rackspace open source policy"
32. B U I L D I N G A C O M M U N I T Y C O D E I S E A S Y
33. H O W T O E N C O U R A G E C O N T R I B U T I O N S • Recognition • Assignment • Be welcoming • Code of Conduct Recognition: call people out on your mailing list, on the website, on Twitter. Give credit Assignment: ASK people to contribute. Flattery will get you everywhere. Some OSS communities have problems because people feel possessive; make sure that contributions are welcome. In many of our projects, we ALWAYS accept pull requests, even if we immediately fix them. ! A published Code of Conduct helps set expectations for people’s behaviors and lets you define what will happen with problematic people.
34. T E C H N I C A L R E Q U I R E M E N T S • Code reviews • Testing • Automation • Willingness to make design decisions Code reviews ensure that all code has eyes on it before commit. This not only improves the quality of the code, it helps ensure that participants are familiar with it. ! Testing is the next level. ! Automation means that it’s trivial to build/deploy/manage the project. Invest in it. ! Finally, someone needs to make a decision. It is ALWAYS better to say “Here’s my idea, stop me if you don’t like it” than “What do you think we should do?”
35. C O D E O F C O N D U C T • Should specify expected behaviors • Should specify consequences of ill behavior • Hard to get right • https://adainitiative.org/2014/02/howto-design-a- code-of-conduct-for-your-community/
36. Q & A S P E A K U P O R S H U T U P
37. DevLink App
 or
 glen@glenc.io F E E D B A C K
38. M E • @glenc • glen@glenc.io • http://glenc.io