Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Principles of Open Source Engineering

Principles of Open Source Engineering

Keynote presentation delivered at the NJSD Global Software Development Conference in 2017 in Nanjing China

Jonathan Lipps

April 21, 2017
Tweet

More Decks by Jonathan Lipps

Other Decks in Programming

Transcript

  1. APRIL 29, 2017
    PRINCIPLES OF OPEN
    SOURCE ENGINEERING
    J O N A T H A N L I P P S , D I R E C T O R O F O P E N S O U R C E
    S A U C E L A B S

    View Slide

  2. April 29, 2017 2
    Director of Open Source
    Project Lead & Architect
    Jonathan Lipps
    @jlipps • @saucelabs • @AppiumDevs

    View Slide

  3. INTRO TO OPEN SOURCE

    View Slide

  4. ”Open Source Engineering”
    April 29, 2017
    The skills and techniques used to develop open source
    software and to build and maintain open source
    projects and communities
    4

    View Slide

  5. What is ”Open Source Software”?
    April 29, 2017
    • Software whose source code is freely visible
    • Software that can be run by anyone
    • Software that can be modified by anyone
    • Software that can be redistributed with changes
    • Software developed in an open, decentralized fashion
    5

    View Slide

  6. April 29, 2017 6

    View Slide

  7. April 29, 2017 7

    View Slide

  8. April 29, 2017 8

    View Slide

  9. April 29, 2017 9

    View Slide

  10. April 29, 2017 10

    View Slide

  11. Open Source: A Tiny History
    April 29, 2017
    • Early software (50s & 60s) was mostly collaborative and public
    domain
    • With the rise of personal computing, restrictive licensing began to
    appear
    • Hobbyists and hackers flowered into the free software movement:
    GNU, Linux running parallel to mainstream
    • New DVCS (like git) and other collaborative tools proved the
    effectiveness of open source development model
    • Corporations now regularly engage in producing and contributing
    to open source software
    11

    View Slide

  12. Why Open Source?
    April 29, 2017
    • There’s always altruism! And ideologies of freedom. But what
    about businesses trying to make money?
    • Why constantly reinvent the wheel?
    • Compete on your product, not the machinery you use
    • Build communities to help make your ideas better
    • By making certain things open, we all benefit (like public
    infrastructure)
    12

    View Slide

  13. April 29, 2017 13

    View Slide

  14. April 29, 2017 14

    View Slide

  15. April 29, 2017 15

    View Slide

  16. April 29, 2017 16

    View Slide

  17. April 29, 2017 17

    View Slide

  18. OPEN SOURCE PRACTICES

    View Slide

  19. The Standard Set of Modern Tools
    April 29, 2017
    • Distributed version control (git)
    • Communication and project organization among maintainers
    • Communication among users and maintainers
    • Method for reviewing and accepting changes
    • CI systems for building and testing changes
    • Distribution and release mechanisms
    • Marketing methods
    • A legal license
    • A community guideline or code of conduct
    19

    View Slide

  20. The Roles
    April 29, 2017
    • Maintainer
    • Responsible for code quality, code review, onboarding new
    contributors, and keeping the project healthy
    • Contributor
    • Contributes code or documentation from time to time
    • User
    20

    View Slide

  21. April 29, 2017 21

    View Slide

  22. Building and Maintaining a Community
    April 29, 2017
    • Projects are more than just code. Most projects live or die
    based on the community
    • Some open source projects are so simple that they can be
    called "done". They don't need much of a community.
    • Most projects are constantly growing and solving new
    problems. For that you need a strong community.
    22

    View Slide

  23. Tips for a Strong Community
    April 29, 2017
    • Exhibit openness. Not just open source but open process.
    • Make it easy to contribute.
    • Minimize amount of process necessary for landing new contributions.
    (Use CI, linting tools, auto-review, etc…)
    • Keep it balanced between strictness of review and giving a new
    contributor a ‘win’.
    • Make sure there’s a clear path to becoming a committer.
    • Reward and recognize community efforts.
    • Build a safe and welcoming community.
    23

    View Slide

  24. Writing Good Open Source Code
    April 29, 2017
    • You can’t pay anyone to look through poorly organized code.
    You want happy volunteers!
    • Prioritize readability and modularity. This is good anyways
    and helps people onboard to your codebase quicker.
    • Ensure your code is documented and that there are
    READMEs for developers in every folder.
    • Create developer-specific documentation.
    24

    View Slide

  25. Governance Models
    April 29, 2017
    • How is your project managed? How are decisions made?
    Who’s in charge?
    • There are different modes, from dictatorship to oligarchy and
    beyond. They can all work in different circumstances.
    • Whatever governance model you have, make sure you are
    transparent about it.
    • …dictatorships don’t get lots of contributions, usually!
    25

    View Slide

  26. Corporate Relationships
    April 29, 2017
    • Corporate ownership of open source projects can be messy
    (FB’s patent clause on React).
    • Open source should be neutral territory, not a battleground.
    • Non-profit foundations can help projects get competing
    companies’ support.
    • The benefits and dangers of paid maintainers
    26

    View Slide

  27. Open Source Inside Companies
    April 29, 2017
    • The rise of “inner source”.
    • The open source development model is a good one, even if
    you’re not producing open source software.
    • You can run internal projects as though they were open
    source for good intra-company collaboration.
    • Be mindful about what’s your core competency and what’s
    not, that you might want to release to the world.
    27

    View Slide

  28. APPIUM CASE STUDY

    View Slide

  29. April 29, 2017 29

    View Slide

  30. Appium’s Tools & Processes
    April 29, 2017
    • GitHub
    • Version control (git)
    • Issue reporting and tracking
    • Code submissions and review
    • ZenHub
    • Project organization
    • Work planning & agile helpers (Kanban)
    30

    View Slide

  31. Appium’s Tools & Processes
    April 29, 2017
    • NPM
    • Release & distribution
    • Dependency management
    • Travis CI
    • Unit tests & linting
    • Functional tests
    • Atlassian
    • CLA bot
    31

    View Slide

  32. Appium’s Tools & Processes
    April 29, 2017
    • Slack
    • Communication between Appium developers
    • Discourse (discuss.appium.io)
    • Communication between users helping one another
    • Announcements to the community
    • Twitter
    • Announcements and community engagement
    32

    View Slide

  33. What Appium Did Right
    April 29, 2017
    • Focused on the community first and foremost
    • Picked an accessible language (JS)
    • Made it easy and fun for others to contribute
    • Got involved with the JS foundation for neutral non-profit
    ownership
    • Stayed mostly on top of user issues; some response is better
    than none
    33

    View Slide

  34. Conclusions
    April 29, 2017
    • Open Source Engineering is an important skill to have as a
    modern developer
    • There are many reasons to consider an open source model,
    even for internal projects. Open source can be mutually
    beneficial even for competing companies
    • The real value of an open source project is the community
    and the maintainability of it, not the code
    • Do you rely on open source projects? See if you can give
    back! I’m sure a lot could use Chinese translations…
    34

    View Slide

  35. THANKS!
    @jlipps • @saucelabs • @AppiumDevs

    View Slide