”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
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
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
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’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
jlipps
alli83
shinmiy
horie1024
hirotokirimaru
tomokusaba
naokimrmt
logiteca7
khmer495
fornewid
twada
stewemetal
maimux2x
jmmastey
davidbonilla
kastner
lauravandoore
keithpitt
jonrohan
tmm1
gr2m
ddemaree
maltzj
mza
moore