. 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
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
T • Existing software at no cost, little effort • Sometimes passionate community to support it • Variable-quality software • Documentation ranging from poor to brilliant
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
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
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
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
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
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
O N S • Coding standards • Test requirements, both unit- and integration-level • Documentation! • Example code • Deadlines are good, but hard to enforce
experimentation and "playing around" (aka "side projects") • Experiment with new tools and technologies • Push them into submitting conference talks • Google "rackspace open source policy"