reasons: • It’s a core, strategic asset and you have an open source business model (i.e. monetization strategy) for it. Ex: MongoDB, Nuxeo, etc. • It’s a non-core, strategic asset you are using in a play against competitors (ex: Google w/ Android) • It’s a non-core, non-strategic asset (ex: Yahoo w/ Hadoop, Facebook w/ React…) and you just want your technology to become the standard (instead of someone else’s) • You’re going bankrupt (ex: RethinkDB) • …
talk, we will assume it’s for non-core non-strategic (i.e. non revenue producing) software aimed primarily at software developers (library / framework)
Get feedback • Get contributors • Share the burden of maintenance with others • Positive image for the company • Recrutement • Internal transformation Costs • Initial costs: Setting up the whole thing • Ongoing costs: • Maintenance (specially for use cases that are not yours) • Communication • It’s a long-term commitment (ex: security)
can “look inside the box”. But more importantly, the development process should be fully transparent too (no closed- door decisions, for instance). Open source is open to use, but also should be open to participation. Deliberate processes, tools and mindsets should be designed to help grow an healthy community. Decisions should be taken by consensus, with all the stakeholders being part of the process, and the needs of the majority (not just the sponsoring organisation) taken into account. Open source values
IP / legal • Organisational and technical (process & tools) External • Indifference • Dealing with users with highly variable environments, tools, needs, experience, culture, etc. • Conflicts (opening the project to potentially toxic people)
two different objectives: community engagement and the benefits for your company • Main license types • Copyleft or not • Patent clauses or not • Probably easier for a non-strategic project • Choose the license that will maximise community engagement as long as you can use the software as intended) • CLA or not CLA ? (Answer: avoid if possible) • Third-party libraries (license compatibility)
easy as possible to get involved as a developer, by e.g.: • Making easy or at least properly documenting how to set up a development or testing environment (➔ Virtualenv, Vagrant, Docker…) • Providing lists of “easy tickets” for newcomers • Welcoming and possibly mentor newcomers, thanking contributors… • Make it hard to derail the project (resilience)
software Making software easy to run Getting more users and contributors Working with people outside your organisations Missions of an OSS project team
Preserve forward compatibility (up to a point) • Deprecation, maintenance of old versions (LTS?), security updates • Relationship with downstream distributors: artefact repositories (PyPi, NPM, Maven, etc.), Linux distributions, Docker images, etc.
/ and) documentation • Pitch your project in 1, 5, 60 minutes • Roadmap and changes • Videos: screencasts and conference talks (don’t forget to link the slide decks too) • Jupyter notebooks • Sample projects & data, SDKs, IDE plugins… • Link to external resources: blog posts, projects using your project… Goal: make it easy for people to discover, evaluate and use your software
users with minimal effort from the development team • Try to grow users into contributors • Online tools: • Mailing list (+ archives!) & forums for announcements, discussions • Ticket trackers for support (Issue templates can be useful) • Synchronous tools (chat) ? - IRC, Jabber, Discord, Gitter… • Participation in outside communities (ex: StackOverflow, Reddit, LinuxFr…) • Also IRL: conferences, meetups, hackathons
it easy to contribute for people with different expertise, schedule, etc. • Remember the 3 core values (openness, transparency & consensus) • Tools • Same as previous slide, plus… • A DCVS and associated tools • Pull requests with comments, templates, etc. • Issue tracker used as task tracker (w/ milestone, etc.) • Wiki for collaborative elaboration of long-term plans • Real life meetings (must be open to all) or on a chat platform
not be a natural skills for some technical people • “Architecture of participation” ↝ Developer Experience (DX) et Developer Relations (DevRel) • Governance: should conform to the three open source values (transparency, openness, consensus) ➔ Clarity of: vision + decision process
the Abilian Developer Guide • Code of Conduct • Release process (i.e. milestones) • Formalised enhancement process (à la PEP, JCP…) • Remember: no decisions behind closed doors • Project templates if you plan to create many small(ish) projects
tracker… • Source code: number of “stars”, contributors, active contributors, contributions over time, time to close a PR… • Support: number of tickets, time to close a ticket… • External engagement: distribution of contributors between internal and external "If you can’t measure it, you can’t improve it.” - Lord Kelvin (wrongly attributed to P. Drucker)
a business decision with objectives and resources that should be defined clearly from the onset, and managed throughout the life of the project • A corporate-sponsored open source project should align the interests of internal and external stakeholders, and must adhere to the open source values to be successful • Strive to learn and adhere to commonly established (and evolving) best practices • Have fun!
• Antipatterns (2010): LCA: How to destroy your community • Jono Bacon: The Art of Community (2012) • Kathy Sierra: Badass Users book — Making users awesome (2015) • The struggles of an open source maintainer - <antirez> (2019)
depend as much on difficult tools 2. Encourage the presence of poisonous people 3. Provide no documentation 4. Make decisions in closed-door meetings 5. Employ large amounts of legalese 6. Choose the wrong leaders / liaisons 7. Governance obfuscation 8. Screw around with licensing 9. Do not allow anybody outside the company to have commit access 10. Silence
sfermigier
line_developers
firebasethailand
yskmjp
ocise
maiamea
nitya
terapyon
tarappo
nishi_yama
eyamane
iktakahiro
picardparis
holman
brad_frost
geoffreycrofte
tanoku
ammeep
deanohume
moore
lara
sugarenia
phodgson
cherdarchuk
orderedlist
