Open-Source in the Real World

Transcript

1. O P E N - S O U R C E I N T H E R E A L W O R L D G L E N C A M P B E L L All photographs ©2014 Glen Campbell
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 ) ?
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
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
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$$$$
6. O S S A D VA N TA G E S • Low-cost • Transparent • Maintained • Community • Shiny
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
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
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 !
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. Q & A S P E A K U P O R S H U T U P
33. https://joind.in/10555 F E E D B A C K
34. M E • @glenc • glen@glenc.io • http://glenc.io