$30 off During Our Annual Pro Sale. View Details »

Open-Source in the Real World

Open-Source in the Real World

Glen Campbell

March 16, 2014

More Decks by Glen Campbell

Other Decks in Technology


  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