#SustainOSS 2018 Notes

Photo credit: https://twitter.com/SustainOSS

Meta thoughts about the event

  • For an unconference, it was extremely well organized and sessions were kept on time, thanks in large part to the team of organizers and the decision to hire an amazing facilitator, Gunner, who had an impressive knack for remembering on-the-fly session topic proposals and people’s names.
  • Loved that the event was intimate, everyone turned their phones off, and because of the very nature of the event (“unconference” = no pre-designated “speakers”), everyone came in as equals with potential knowledge to share. Reportbacks from each session were brief, and people were encouraged to connect with as many other people as possible without being self-promotion-y. I jotted this down: it was a “day to honor constructive selfishness.”
  • Nice touches: there was a film crew recording interviews for about two hours during the event, and the after-party was on the 7th floor at Google/Youtube UK with a great view of London.
View from Google UK.
  • Travel scholarships and childcare during the event were offered. (PS If the idea of this event appeals to you at all but you may need travel or Visa assistance, look on sustainoss.org for a link to apply to a scholarship next year! SustainOSS was held in San Francisco last year and London this year. The location is TBD next year.)
These sticker nametags sponsored by StickerMule were awesome.

General challenges/trends reported by OSS projects

  • Hard to find designers
  • Hard to find documentation contributors, and contributors willing to take on “easier” maintenance issues (not the coding ones).
  • Given a budget, how do we spend it?? Most often it is developer time, not money, that projects need the most. Maybe a bit of money could help buy some developer time, but most projects do not have enough to work with.e
  • Developer attention is a scarce resource.
  • Give contributors time to vote. The Apache project historically gave members a 72-hour window in which to vote, accommodating for the fact that people were from around the world.
  • Historically, most OSS projects were built by people from around the world, and they’d be friends for years online before meeting for the first time at conferences.
  • Maintainer burnout often happens when there are not enough core contributors to respond to opened issues and un-reviewed PRs.
  • Sometimes the least fundable projects are the OSS tools that sit in infrastructure — that plenty of companies use, but are unwilling to pay for upgrades
  • Microsoft becoming an OSS champion makes a lot of sense, actually; it was easier for developers to onboard on open source projects rather than have to learn proprietary software
  • Product management/project management skills are often the most valuable (and the most underestimated) skills in OSS projects
  • Turnover/churn in OSS projects is good. Mentees must be ready to step up.
  • The question core maintainers must ask and prepare for: can the project be sustainable without me?
Technically phones were supposed to be off, but I snuck this photo during the round of appreciations

Questions I would love to read summaries of in the 2018 reportback

  • What is “fair compensation” for contributors?
  • How do we lower the barrier for new contributors to join?
  • How do we get more upstream labor into OSS projects from companies already benefiting from those OSS projects, e.g. VueJS, Webpack, Django, or Babel? (Or is it even a thing that OSS projects want and could benefit from, vs. getting contributors motivated more by pure passion/interest?? Is it easier to simply pay designers, and pay students to come to sprints?)

Top 20 Actions an OSS project maintainer can take

  • Have a Code of Conduct
  • Express gratitude
  • Have documentation about the architecture
  • Display contributor GitHub avatars on README.md
  • Use issue templates or PR templates (Github)
  • Give contributors discount on swag in shop
  • Give away stickers
  • Document the process for getting out of the community (maintainers stepping down)
  • Recognize status (maintainer vs. collaborator)
  • Communicate roles
  • Value equally different contributors over the scale of a project
  • Train maintainers on people management
  • Choose a community tool for hanging out / synchronous chat
  • Create a social space (“what did you work on last month?”)
  • Treat newcomer contributors like future core maintainers
  • Label issues good-first-issueor good-for-beginners
  • Have a fast build
  • Have good test coverage
  • Use linters/autoformatters
  • Pick a source management system (may not be GitHub)
  • Have an “offboarding” plan for key contributors who would like to step down
  • Have an open source license.

My personal next steps

  • a maintainer of an OSS project
  • a new contributor interested in getting a codebase walkthrough

--

--

--

Developer, formerly @actionkit and @moveon. Creator of codebuddies.org, youtube.com/lpnotes, and wannabe composer. Always learning.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How Java would be at the center of 5G-IoT evolution

Serverless vs Containerization

Docker Out-Side Docker

Xero Connector for Dynamics 365 CRM

Golang Integration Testing Made Easy

Protocols, Delegation & SwiftUI2.0

My Coding Journey

Java Syntax

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Linda Peng

Linda Peng

Developer, formerly @actionkit and @moveon. Creator of codebuddies.org, youtube.com/lpnotes, and wannabe composer. Always learning.

More from Medium

OSD 0.4 — Planning and Progress

Using Apache Nifi for Enterprise Workflow Automation

Document your old projects and code