Slide 1

Slide 1 text

Stéfane Fermigier Founder & CEO, Abilian - Enterprise Social Software Corporate open source development (When you’re not an open source software vendor) 26 May 2019

Slide 2

Slide 2 text

About me • PhD in mathematics • Free / Open Source user since 1988 • Linux user since 1991 • Python developer since 1996 • PyData Paris / PyParis founder / (co)organiser (2014-2018) • Co-founded AFUL, EuroLinux Alliance, GTLL, CNLL • Founded 3 companies: Linbox (1999), Nuxeo (2000), Abilian (2013) • Launched a few open source projects: Nuxeo CPS, Nuxeo EP, Apache Stanbol, Apache Chemistry, Eclipse Apricot, Abilian SBE, OlaPy… • “Expert” in open source R&D projects evaluation

Slide 3

Slide 3 text

Before you start

Slide 4

Slide 4 text

Why open source your software (as a company)? Depends on the kind of product you are considering open sourcing: • B2B or B2C • Business or technical • Core or not • Strategic or not

Slide 5

Slide 5 text

Why open source your software (as a company)? Many possible 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) • …

Slide 6

Slide 6 text

Why open source your software (as a company)? In this talk, we will assume it’s for non-core non-strategic (i.e. non revenue producing) software aimed primarily at software developers (library / framework)

Slide 7

Slide 7 text

Costs and benefits Benefits • Improve your software quality • 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)

Slide 8

Slide 8 text

What’s an open source community? • Shared values, goals, vision & rules • People > Code • But overall goal is to create quality software (paradox) • Natural progression (funnel / ladder) PROSPECT / LURKER USER (PASSIVE -> ENGAGED) CONTRIBUTOR / DEVELOPER CORE DEV

Slide 9

Slide 9 text

Transparency Openness Consensus Open source code is freely available, one 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

Slide 10

Slide 10 text

Main challenges Internal • Shared objectives and vision (internally) • 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)

Slide 11

Slide 11 text

Legal issues: Licensing and CLA • License choice means maximising 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)

Slide 12

Slide 12 text

The Architecture of Participation (O’Reilly, 2003) • Make it as 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)

Slide 13

Slide 13 text

Daily life of an open source development team

Slide 14

Slide 14 text

Development Packaging & Distribution Marketing & Support Collaboration Making great software Making software easy to run Getting more users and contributors Working with people outside your organisations Missions of an OSS project team

Slide 15

Slide 15 text

Tools to supports these missions • “Forge” (GitHub ? Gitlab ?) • CI / CD • Automated metrics and quality audit + Human code reviews • Web site / Documentation site • Communication tools

Slide 16

Slide 16 text

Development, packaging and distribution Building & shipping great software

Slide 17

Slide 17 text

Specific tools for Python projects • Virtual env management: Virtualenvwrapper, Pipenv… • Test harness: pytest, tox… • CI : Travis, Gitlab CI, Azure Pipelines… • Documentation: Sphinx + Read the docs • Formatting: black • Linting: flake8 + plugins, mypy, pylint • Packaging: Setuptools, Poetry…

Slide 18

Slide 18 text

Releasing and packaging • Versioning: semantic vs. time-based ? • 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.

Slide 19

Slide 19 text

Communication & Collaboration

Slide 20

Slide 20 text

Communication: towards users Some tools • Marketing (logo, swag…) (vs / 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

Slide 21

Slide 21 text

Key documentation artefacts or parts In the source code • README (.txt / .md / .rst) • LICENSE (of course!) • NEWS / CHANGES • ROADMAP / TODO • CONTRIBUTING / COC • CONTRIBUTORS Outside the source code • Pitch / Vision (functional & technical) • Tutorial • Reference (API) • Mostly autogenerated from source (e.g. Sphinx) • Include some of the resources on the left column See: https://tom.preston-werner.com/2010/08/23/readme-driven-development.html 
 & https://www.writethedocs.org/

Slide 22

Slide 22 text

Communication: with users • Main goals: • Provide support to 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

Slide 23

Slide 23 text

Collaboration: with contributors / developers • Main goals: • Make 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

Slide 24

Slide 24 text

Organisational considerations

Slide 25

Slide 25 text

Managing an open source community • Dealing with humans may 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

Slide 26

Slide 26 text

Useful tools • Contributing guide • Example: How We Work: 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

Slide 27

Slide 27 text

KPIs / (Vanity?) Metrics • Usage: number of downloads, usage 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)

Slide 28

Slide 28 text

Conclusion

Slide 29

Slide 29 text

Key takeaways • Going open source is, for a company, 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!

Slide 30

Slide 30 text

Questions ?

Slide 31

Slide 31 text

Annexes (not shown during presentation)

Slide 32

Slide 32 text

Some references • Open Source values (2007) by Dana Blankenhorn • 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 - (2019)

Slide 33

Slide 33 text

The 10 antipatterns by Josh Berkus 1. Make the project 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

Slide 34

Slide 34 text

Credits & License License for this presentation • Creative Commons CC-BY-SA Image credits • https://pixabay.com/photos/raindrops-transparency-green-nature-1532618/ • https://pixabay.com/illustrations/hands-finger-touch-team-teamwork-1691221/ • https://pixabay.com/photos/illuminated-light-neon-light-sign-1853924/ • https://pixabay.com/illustrations/megaphone-loud-speak-communication-1725694/ • https://pixabay.com/vectors/box-packaging-2071537/ • https://pixabay.com/photos/team-team-building-success-computer-3373638/ • https://commons.wikimedia.org/wiki/File:HAL9000.svg