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 

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

INTRO TO OPEN SOURCE 

”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 

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 

April 29, 2017 6 

April 29, 2017 7 

April 29, 2017 8 

April 29, 2017 9 

April 29, 2017 10 

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 

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 

April 29, 2017 13 

April 29, 2017 14 

April 29, 2017 15 

April 29, 2017 16 

April 29, 2017 17 

OPEN SOURCE PRACTICES 

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 

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 

April 29, 2017 21 

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 

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 

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 

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 

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 

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 

APPIUM CASE STUDY 

April 29, 2017 29 

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 

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

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 

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 

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 

THANKS! @jlipps • @saucelabs • @AppiumDevs