Icon blog
Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

Creating a New Source of Revenue for Open Source Software

By Guillaume Luccisano on Oct 23, 2018

Creating a New Source of Revenue for Open Source Software

Triplebyte is giving every user on our platform $100 to donate to their favorite open source software (OSS) project. In this blog post I want to explain why funding OSS is worth $20k every month to our company—and why we think you should care about it too. You can see where these donations are going on this page.

“Open Source” Doesn't Mean “Free”

I'm a software engineer by trade, so I code a lot for work (and in my free time). I use iTerm2, and I mostly code in Ruby these days, using Homebrew, RVM, Bundler, and Rails. As of this morning, our Rails app relies on 279 gems including RSpec, RuboCop, and Curb. And to store our data, we use PostgreSQL and Redis.

All of this is free. And to tell you the truth, I've always taken that fact for granted. You probably have too.

But we need to take a step back: All of this is free, but only from our perspective. Software doesn't spring forth from the ether ex nihilo. Which means some selfless person out there is devoting countless hours to make my life easier. Essentially, they are giving up time (i.e. money), so that I can save time (i.e. money).

The open source ecosystem is one of the most impressive and significant social experiments of the last century. It is a vast, decentralized volunteer movement which has achieved far more than any single programmer or corporation could. Programs that were incredibly difficult and time consuming to custom-build 20 years ago are now widely available for free.

However, OSS suffers from the tragedy of the commons: because OSS is a shared resource, no one feels individually responsible for taking care of it. So, most of us take its benefits without giving back for its upkeep. The majority of OSS projects are maintained by small groups of volunteers who pour their blood, sweat (and sometimes tears) into the thankless task of maintaining a vast codebase most of us take for granted. It's worth remembering that our current productivity depends on the free labor of the many OSS maintainers who have gone before us.[1]

Companies Should Fund Open Source

Companies rely on OSS just as much as individuals. Businesses large and small save billions annually by using OSS—savings which they can pass on to consumers. The tech economy relies on OSS in the same way that the shipping economy relies on basic infrastructure.[2] It's as if a few underpaid OSS maintainers are paving our roads, building our bridges and railways, and dredging our ports and shipping lanes. That said, I believe companies have a vested interest in funding OSS. And, of course, some big companies are doing just that, creating partnerships with projects that serve their best interests. However, we think that big corporate sponsorships may not be the only, or possibly the best, way to go about funding OSS.

Crowdsourcing Open Source Funding

When our company first started thinking about contributing to OSS projects, we set aside some money in our budget for projects we relied on heavily. I think it was a good first step, but not optimal, or in keeping with the spirit of OSS. Just having our engineering team pick projects to fund is a major limitation because we aren't familiar with many of the really great projects out there, especially the less flashy ones.

We decided that crowdsourcing our funding decisions would be a better solution that might lead to more meritocratic choices. We wanted the process to be bottom up instead of top down just like OSS itself. Luckily, since lots of programmers use our platform to find jobs, we have an unusually easy way to put funding decisions into the hands of the people who use OSS every day and know it best. We hope to leverage the accumulated wisdom of the thousands of engineers who go through our platform by giving them a small amount of money to give to their favorite projects. Our hope is that this decentralized approach—the same non-hierarchical approach which, incidentally, makes the OSS ecosystem so fertile in the first place—will be a better way to fund OSS projects as well.

Starting today, thanks to a collaboration with Open Collective, every software engineer accepted onto our platform will receive $100 to give to their favorite OSS projects (if you have a project that needs support, Open Collective is the platform to be on).

We're also excited about other potential revenue streams for OSS like Read the Docs' ethical advertising initiative, or placing unobtrusive sponsor messages on OSS project sites.

Our approach is different in that we're essentially shifting a portion of the HR budgets at companies who hire through our platform towards OSS funding, but we think that more funding sources are always better. A lot more needs to be done by companies to fund OSS projects if the ecosystem is going to thrive and be sustainable over the long term. We have another exciting announcement coming soon about a further step we'll be taking to say thank you to the OSS community, so stay tuned. In the meantime, this initiative should funnel about $20k to OSS projects and maintainers in its first month. And as we grow, this amount will increase.

The OSS community continues to give countless hours and forego bigger paychecks in order to make our lives easier. Their volunteer work saves billions of dollars every year. Let's give a fraction of that back to support the people who are supporting us.

If you're an engineer and are interested in finding companies where you're a strong technical match—and want $100 to give to your favorite open source project!—give our process a try. I'd also love to hear your thoughts on this topic! Send me an email at guillaume@triplebyte.com. Thanks!

[1] For more on OSS maintainer burnout, see this article.

[2] I am indebted to Nadia Eghbal for this metaphor. See her excellent study produced for the Ford Foundation.

Get offers from top tech companies

Take our coding quiz

Liked what you read? Here are some of our other popular posts…

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More

Bootcamps vs. College

By Ammon Bartram on May 19, 2016

Programming bootcamps seem to make an impossible claim. Instead of spending four years in university, they say, you can learn how to be a software engineer in a three month program. On the face of it, this sounds more like an ad for Trump University than a plausible educational model.

But this is not what we’ve found at Triplebyte. We do interviews with engineers, and match them with startups where they’ll be a good fit. Companies vary widely in what skills they look for, and by mapping these differences, we’re able to help engineers pass more interviews and find jobs they would not have found on their own. Over the last year, we’ve worked with about 100 bootcamp grads, and many have gone on to get jobs at great companies. We do our interviews blind, without knowing a candidate's background, and we regularly get through an interview and give a candidate very positive scores, only to be surprised at the end when we learn that the candidate has only been programming for 6 months.

Read More

How to pass a programming interview

By Ammon Bartram on Mar 8, 2016

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More