2019-corporate-open-source.pdf

Transcript

1. 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
   

   View Slide

2. 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
   

   View Slide

3. Before you start
   

   View Slide

4. 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
   

   View Slide

5. 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)
   • …
   

   View Slide

6. 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)
   

   View Slide

7. 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)
   

   View Slide

8. 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
   

   View Slide

9. 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
   

   View Slide

10. 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)
    

    View Slide

11. 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)
    

    View Slide

12. 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)
    

    View Slide

13. Daily life of an open source development team
    

    View Slide

14. 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
    

    View Slide

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

    View Slide

16. Development, packaging and distribution
    Building & shipping great software
    

    View Slide

17. 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…
    

    View Slide

18. 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.
    

    View Slide

19. Communication & Collaboration
    

    View Slide

20. 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
    

    View Slide

21. 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/
    

    View Slide

22. 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
    

    View Slide

23. 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
    

    View Slide

24. Organisational considerations
    

    View Slide

25. 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
    

    View Slide

26. 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
    

    View Slide

27. 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)
    

    View Slide

28. Conclusion
    

    View Slide

29. 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!
    

    View Slide

30. Questions ?
    

    View Slide

31. Annexes (not shown during presentation)
    

    View Slide

32. 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)
    

    View Slide

33. 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
    

    View Slide

34. 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
    

    View Slide