My next open source project: a project for others

After years of working on publishing open source articles (mostly about git) and helping get the Ruby community’s flagship code distribution service off the ground — I’m not currently contributing to any major project for the first time in my career. For years it’s been my privilege, a hobby, and at times an obligation to contribute to OSS. I’ve been reflecting on this and considering:

What do I want my next project to look like?

My 3 year old’s latest project was contributing a rocketship to this open source legal pad.

Let’s back up. My focus on OSS was at first to get some experience to help land a job after graduating. I was desperate to land a job building software that I liked and not to be stuck in a big corporate wasteland post-graduation.

In 2006, I applied for a Google Summer of Code to work on Moodle and got rejected. I pulled up the proposal I sent back then, and it’s a painful joy to re-read:

At least no one uses AJAX-integrated interfaces anymore.

8 years ago (what!) I asked this question on /r/programming:

The second comment still sticks with me. Also I’m quite sure this was the only subreddit.

I don’t remember much else about 2008 other than pulling my first lever to vote in a presidental election. A few months after that Reddit post, the first code I was published to GitHub was a simple Snake game written in Shoes.

Around this time I was under the delusion I could be a game developer. Amazingly, the game still runs without any modification, which is a feat on its own right for 8 year old Ruby code:

It’s still difficult!

Even my well-known projects started out as mostly self-serving. I wanted to learn more about git. Publishing a ruby gem was too difficult. The documentation site for RubyGems lacked good long-form tutorials.

I think most open software gets developed in this way: to fulfill a need for oneself. Keep yourself motivated to finish something. Push yourself to keep working on it.

These feelings as an impetus to create a project and a motivation for working on them is not a bad thing — but it feels exactly what it is:

Selfish.

Fundamentally, I believe open source software is selfish. Even down to campy slogans like “Scratch your own itch”, the need to fulfill one’s own purposes as motivation is deeply embedded into OSS culture. It’s rare to find a freely available software project that isn’t self-serving. A creator made it for themselves. A company built it for their purposes. A team maintains it for their usage.

The MIT license, arguably the most popular open source legal document in my professional circles, has this selfishness bias succinctly built in. Emphasis mine:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The legalese reflects this tenet. This software is mine (or my business entity’s), and that’s all there is to it. I owe you nothing here. YOU are an afterthought, a legal writeoff. US? Get out of here.

Projects for others

Looking back at my programming career so far and thinking about what the next decade will bring, I’ve come to peace with the following:

1. JavaScript isn’t going anywhere for another 10 years (at least)
2. My next open source project will be a project for others, not myself

What does a project for others look like? Here’s some baselines:

Community first

Having a Code of Conduct for your project’s communication standard is a bare minimum now. I’ve struggled to keep people involved with toxic teams in the past. It’s not worth it. It’s sad this has to be said, but: if football stadiums, malls, and even open public spaces have code of conducts — there should be NO problem considering one for your globally visible project where others participate in a professional manner.

Providing a safe environment to contribute code, ideas, designs, and more with others is just table stakes in 2016. I am excited to see how far this approach can go in the next decade to bring in more people who may have never considered contributing before because this approach explicitly lays out a welcome mat for marginalized people, underrepresented people in tech, and those who may not have had access at all to technology. There’s going to be 9 BILLION people on this planet by 2050. What are you doing to involve and serve more than just those in your immediate circle of developers?

Projects for others consider their community of developers and users their most valuable asset and drive their focus outward, not inward.

Pay people to do work

My friend Ashe unknowingly gave me a great birthday present 3 years ago: she shattered my ideas around who, how and why people work (and don’t have the privilege to work on) open source software. It all comes down to compensation:

Ask any open source project maintainer, though, and they will tell you about the reality of the amount of work that goes into managing a project. You have clients. You are fixing issues for them. You are creating new features. This becomes a real demand on your time.

Paid or not, play or not, this is labor that is currently not being compensated.

I strongly feel the most radical thing that could be done in an open source project for others would be to PAY PEOPLE TO WORK ON IT!

Legally and finanically this is a wormhole, but it’s doable. If the project is successful and useful, the pieces will fall into place. From the start if the goal is to be a sustainable project and help pay people, especially for those who haven’t contributed yet to open source, and compensate them for their time — I think it’s possible.

I see this as another avenue to reducing guilt in open source: I would feel a lot less guilty assigning “low hanging fruit” tasks to others if I knew they’d be compensated for it. It’s even an sweeter deal to provide motivation to dig into complicated issues if there’s a paycheck waiting at the end of it. I’ll bet this will help reduce maintainer turnover and burnout too.

Projects for others are sustainable for their developers and compensate those who work on them for their labor.

The code won’t matter

Many projects use their language of implementation as their selling point to attract developers. It’s usually boasted about terms that solve surface level problems: LEGIBLE FOR HUMANS, QUICK COMPILE TIMES, EASY DEPLOYS! The list goes on.

I don’t believe a project for others should care about the actual language what it’s implemented in. Sure, it’s the ultimate product of work on open source software and it is important, but it’s second fiddle to documentation.

I’ve spent more time writing prose in English to answer questions, write tutorials, and fill out FAQs while working on open source projects than writing code. Code is the easy part. Explaining what you did and how it works is a more valuable skill.

This is a non-scientific claim, but I would wager this time difference exists for most “core” maintainers of popular open source projects. I’d love to hear if it’s not and why for you.

Projects for others consider code secondary to written language explaining usage, processes, and policies.

Localized future

I’ve dealt with localization and “i18n” several times with my open source work. It’s a truly humbling experience to realize someone who might not speak or write your native tongue primarily wants to use your software. I’ve worked with many folks who have helped translate my words into their languages and provided a way for them to publish their writing alongside mine.

I think OSS can go a step further than this. I was inspired when I first saw Koro, a way to use Bengali to write Go code. Even its “Hello, World” program shows the tip of the iceberg:

package main

import "fmt"

ফ main(){
    যদি true {
    fmt.Println("Hello, world!")
  }
}

I was lucky to catch Koro’s author Aditya give a talk at Alterconf last weekend in NYC. A few points truly struck home:

Recognizing your project can be useful on a global scale means using more than just English to communicate its message. Your job as a native English speaker and writer is to unlock access for others, not to exclude them by saying one language is the “lingua franca” of a project. International usage of your project should not be an afterthought, it is the present and future of your code.

Projects for others view English as one of many possible languages contributors and users of their software will know, and provide a way to localize everything from documentation to error messages.

Security from the start

I’ve had a few harrowing experiences with security issues on my open source software. The worst being learning my site was hacked while commuting:

I keep the banner magic pink to remind myself to not take this website seriously

Please don’t make this same mistake I made nearly 4 years ago. Security should not be an afterthought for any open source project, let alone one that focuses on others.

“Security” itself is a nebulous term and poorly defined. Let’s break it down. Projects should, at a minimum:

1. Understand that insecure code is a reality of software engineering, and be ready to react
2. Have a clear path for reporting security issues and who is responsible for responding to them
3. Respond in private to security researchers, and publish post-mortems about how issues were solved in public

Platforms like HackerOne are a great way to implement these procedures on a larger scale, but it’s easy to just get started with a simple SECURITY document and an email address to report issues to. I wish GitHub and other source code hosts would help with this process: one doesn’t need to navigate maze to learn how to properly deal with fixing insecure code and doing due diligence on reporting it. Having guidelines in place to handle security problems from day one will reduce stress for maintainers and embed responsibility deeply into the project.

Projects for others have a security plan from the start and a solid way to protect consumers of their software from malicious usage.

“Invariably starry-eyed time-wasters”

I don’t know what my next project will be, but I want to move past this “selfish” feel and focus on others in my future open source software endeavors. The others who might work with me on it. The others who might use it and stumble on installing it. The others who will maintain it once I’m gone. The others who will seek to learn from it as they build on top of its legacy. For now, I’ll stare, starry-eyed, wasting time on the Internet, until I can figure out how to help them.

I’d love to hear about your experience implementing these ideas in your communities — and especially if your project has done any of the above successfully! Thanks to Jim Mackenzie and Jamey Hampton for reviewing this post.