5 short stories from open source: pains in gains

By Lynn Langit on September 14, 2016

Lynn Langit, Cloud & Data Architect Director of Teaching Kids Programming (slides)

She tells the story of Matt, a fifth grade history teacher who wrote some bacon-related code in Swift

Lynn’s daughter has been coding since age 8 and taught Matt how to code.

Matt now teaches Java to 8th graders.

Matt wanted to understand how he could contribute to open source. TKP introduced him to the world of open source on GitHub. They made a portal website explaining their libraries and what GitHub is.

Your job today is to find a Matt.

Jason Chen, Quill: open source DDOS (slides)

GitHub Issues have 2 properties:

  • anyone anywhere can create an issue,
  • but it often takes time and effort for maintainers to create complete and thoughtful response

These are classic characteristics of an ideal Denial of Service attack scenarios.

At one point, Jason was spending all his time answering GitHub Issues instead of building new features.

An obvious solution was just to spend less time on Issues, but that’s bad, because users feel ignored and post mean memes to your project.

An better strategy is to ask for clarification instead of trying to guess what an issue reporter is trying to say. “Can you elaborate? What did you mean by X?” This doesn’t take a lot of your time, but shows that you are super responsive.

Asking for clarification tells a user you are responsive to their needs, so they will in turn reciprocate by investing time into composing a more detailed description of their issue. If you’re lucky, they may even end up answering their own questions.

So if you’re unclear about something, “just ask for clarifications.”

Gregor Martynus of hood.ie: Growing a healthy community by dedicating space (slides)

How can you get more people to become active contributors to your project?

Thanks to GitHub, collaborating on code is easier than ever. But open source is intimidating. Lack of tooling is no longer the bottleneck. People issues are. If you aren’t good at fostering an inclusive, welcoming culture, you’re missing out on great potential contributors.

Hoodie is trying to be one of open source’s most diverse and inclusive communities. To foster this, they created a dedicated space for contributors and community members: hoodie.camp. It’s built on top of the GitHub API.

Bringing back open source projects to life, Enrique Mogollan, Software Engineer at Salesforce Desk

A while back, Enrique found a bug in an open-source dependency. He explored the code and submitted a pull request. It took 7 weeks for the change to be merged. He felt that the project was important, though, so he continued to contribute and invest in it. After awhile, one of the contributors invited Enrique to become a contributor himself.

Open source projects die or fade for a variety of reasons: maintainers move on, lose interest. Why should we rescue projects?

  • It might be depended on by something somewhere
  • Security and trust are important values of open source and to ensure these, the code needs to be kept up to date.
  • There’s potential to build new features and fix new bugs that can benefit others.

How can you start?

  • Writing documentation
  • Contact the maintainers and express your gratitude

Even if a community is dormant, they can still be woken up and act as a team. Biggest bottleneck in open source is time. And the solution to that problem is greater collaboration. The future of open source is the community.

Quinn Murphy, NetSuite (slides)

Open source is everywhere, but change is still frightening. Imagine you’ve discovered a great open-source project, but it’s still unknown to the stakeholders in your org.

Fighting for open source is a lot like Street Fighter.

How do you convince people? It’s like the Street Fighter Training Room. Show, don’t tell .The future is hard for people to see, so give them as many chances to interact and play around with the new thing.

“Learn to block.” Guard your lifebar. An open source library is going to some things well, other things poorly. Explain the tradeoffs before people point out the flaws. No solution is perfect.

“Know your matchups.” Tell different stories that appeal to different stakeholders.

“Understand the benefits of standing still vs moving forward.”

“Learn to lose” — failure is feedback. Learn from losses so you can win the next battles.

“It’s never Game Over.” It’s only over when you quit trying.