We’re Victor and Tony, founders of DevFlight (https://devflight.com). We help open-source maintainers make money. Think of us as agents for open-source maintainers.
We met last year through the Indie Hackers community. It’s one of the luckiest things that’s ever happened to us. We clicked immediately. It became clear we share an obsession with building things to make developers’ lives easier. We began working on small developer-centric projects together.
We started DevFlight after recognizing maintainers are the most underserved developers. They provide immense value and get little in return. We’ve spoken with many maintainers who’ve told us the current open-source development model is unsustainable for them. Their projects often end up being a second full-time job without pay. Some have to stop supporting their projects altogether due to a lack of resources.
It’s time to start paying maintainers well for their work. Making open-source development sustainable will benefit everyone in the long-term. Our vision is to make it possible for maintainers to receive a stable income that accurately reflects the value they bring to companies. We’re accomplishing this by connecting maintainers with companies who will pay them.
If you’re a maintainer, apply now on our website to join the waitlist. We’re currently working with a small group of maintainers from popular projects. We’ll gradually expand this group. Shoot us an email to learn more. We’d love to chat with you.
We aim to make the process of hiring maintainers dead simple for companies. We communicate when maintainers are available and what types of work they can provide. If your company is interested in learning more, please reach out to us.
Companies are paying for things like priority email and on-demand support from maintainers, feature request prioritization, continued development of the project, faster bug fixes, and guaranteed project stability. This is not an exhaustive list.
We take 10% from every contract we negotiate. We’re aware the contract model doesn’t work for everyone. We’re exploring other revenue models based on what’s best for our maintainer network. We’d be particularly interested in hearing any ideas about this from the HN community.
This is a difficult problem to solve, because it’s fundamentally more of a human problem than a software one. Companies often aren’t aware of all the open-source software they’re dependent on. Many also have complex purchasing requirements and no clear understanding of how their company can directly benefit from paying maintainers. Solving this problem requires better communication, more transparency, and new systems.
We know the HN community has a wealth of experience and knowledge on this topic. We’re excited to listen to any thoughts and experiences you’re willing to share with us. We want to continue to learn and evaluate how we’re approaching this problem, so fire away!
Victor and Tony
I'm looking for new opportunities in the market and one of the things that I would really love to do is work 100% of my time with opensource projects (as I had in the past until management decided to make my main repository private - one of the reasons why I'm thinking about moving forward) and I really believe there is space for donation-based systems to grow because most I have seen so far seems good enough but something important should be missing because I don't see too many projects getting donations and many times the total amount is just barely enough for going to a nice restaurant once a week.
Maybe something better integrated with GitHub and someone else would be responsible for reaching out people who benefits from the project to ask for donations would work out better.
Gitlinks (https://www.youtube.com/watch?v=VdaQE6FpM_Q) is an acquired startup that tackled that problem by identifying open-source projects that a company relied on and auditing the code to find security vulnerabilities. Might be worth it to get in touch as I think their technology could be helpful to you.
https://shoptalkshow.com/episodes/344/
One guy maintaining code that powers tons of development workflows, funded completely on donations. He spends much of the show wondering out loud just how the heck he's going to make it work!
A tangentially related idea I've had for helping fund OSS is offering a service that generates a passive revenue stream for projects via merchandise/swag sales. Essentially, the project gives you a license to use their IP (logos, slogans, trademarks, etc) for use on merchandise, then you operate an online store that provides branded merchandise for the project and provide a royalty back to the project based on a percentage of profit.
It can be as passive as the maintainers want, other than (potentially) creating a CNAME to the online store and adding a link to their website. All of the operational aspects of running an online store are completely abstracted from the maintainer, and they just get a periodic royalty payment. Or as active as they want, if the maintainers want to take part in designing (or approving) the merchandise, promoting it, etc.
The passive version also works perfectly for 501(c)3 non-profits, as the royalty payments would qualify as an exception to the "unrelated business income" rules and be considered tax-exempt revenue[1].
The size of the revenue stream is pretty proportional to the popularity of your project, so hidden projects with lots of indirect users would likely only generate a modest amount of revenue. But projects with a lot of direct users/site traffic or an engaged/passionate community would likely be a hit, from individuals buying stuff directly to manager's buying swag for their team.
If there are any project maintainers that would be interested in exploring the idea, please reach out (email in profile)! I can cover the execution side of things, and would love the chance to validate the model.
[1] Based on a naive reading of https://www.irs.gov/pub/irs-pdf/p598.pdf
Their website copy focuses on "the maintainer's" project, and DevFlight's comments on this post repeatedly reference leveraging any community channels the maintainer created (such as social media and Slack) for outreach. As well, the example list of projects they listed above has a presumption of authority/control over the project or else they don't make as much sense - you can't guarantee things like project stability or prioritize features without having some presumption of authority over the project to back it.
While DevFlight is focusing on the individual, from what I can tell it's specifically on individuals that are project maintainers, and not simply prolific contributors. From a corporate standpoint, those are two vastly different sales pitches. If the maintainer of the project commits to prioritizing feature requests or stability of the project, then they have the actual authority/capacity to follow through on that commitment. A prolific contributor might have the expertise and familiarity with the project to make those commitments, but if the maintainers have other ideas, the contributor would have no resolution other than to fork the project to maintain their commitment. Then the company is operating off of a custom fork of the project, maintained by a single person and not as battle tested as the official project, which may or may not have to deviate further away from the official project over time depending on what the contributor committed to vs. where the official project is going.
Companies hire third parties to customize, integrate, and support software all the time. And a prolific contributor to a project is a really good individual to choose for that type of work. The conversion rate for cold selling those services via outbound lead generation, without the weight of someone who can speak authoritatively on behalf of the project, will be significantly lower though.
Hopefully Victor or Tony can chime in and provide some clarification on who their target audience is. :)
I still think GitHub should have a bounty program.
OpenSource has an unusually large impact on the world. Let’s pay people great money to have that impact.
What are the project requirements or qualifications necessary to sign up?
What's the expected input from the developer/maintainer?
How much money are maintainers expected to make?
Also, what exactly does DevFlight do? What tactics do you use? How do you decide who to "target", and how (and how often) do you contact them? I'm assuming the developer sees (and has veto power) over all the communications before they're made?
Part of the site and part of the intro here makes this sound like it's just a job search?
The primary maintainer input is getting us up to speed on their project goals, work preferences and existing communities. After we have a good understanding of their preferences, the maintainer can choose their level of involvement. Maintainers can be as involved as they like after we begin our campaign. We provide a weekly update detailing who we’ve reached out to and the status of each communication. We can provide this information on a daily basis as well.
As far as tactics, we start by collecting publicly available GitHub information related to the maintainer’s repo. This includes looking at who has engaged with projects by doing things like submitting issues, pull requests, and stars. We also use social media and any community channels the maintainer has created (Slack, Gitter, Discourse, etc.). Then we act as the maintainer’s sales team by reaching out to these leads via a variety of different channels (email, social media, phone, real-time messaging). We find the right people within an organization to discuss how the maintainer can add value to the company, and we negotiate contracts based on the custom plan we’ve developed with the maintainer.
> What is the Tidelift share?
> We don't want to lock this number down until we have more data, but can commit that the majority of subscriber fees will be paid out to lifters.
You can read more about it here: https://tidelift.com/subscription and you can search through the packages and get some cool info for a maintainer here: https://tidelift.com/about/lifter
I DO NOT WORK FOR THEM. Just think this is the future of sustainable open source.
Why? Because who is gonna pay for yet another react select component library that you made. Yes, it's convenient for us to use it, but it's also convenient for you that we use it, because we can also contribute and save each other's time.
I do, though, support the idea of paying maintainers of really big and crucial projects. I'd also love to see companies giving some work time to devs to contribute to OS, instead of being forced to do it in their own time.
I think if the software brings you value, you should return some of that value to support ongoing development - at the end of the day you’re going to benefit from the software you depend on being better developed. It’s incredible to me that people don’t support the OSS they use and then spend huge resources switching to a different vendor (e.g. PostgreSQL to MySQL) for something that could have been avoided if they were supporting the OSS from the first place. Supporting OSS is almost an insurance policy against having to rewrite/migrate.
I've mentioned this in other HN threads, what I'd like to see is a donation system integrated into the Git platform (e.g., GitHub, GitLab, etc.). In short, I buy credits and give them to projects as I see fit. Those projects could in turn give credits, or cash out. The credits can also be used to pay feature bounties and award contribuors.
Sure. Parhaps I only give $5 here or $20 there, but the ease would add up. With the key being the ecosystem created.
Somethink like that.
I'm certainly in favor of new ideas and experimenting, etc. But when it comes to OSS I feel there are times when two or three rock solid products would be better than six or seven or more.
EDIT: In fact, commercial use is only available via the commercial license, even if a company decides to build their own binaries.
Helping open-source maintainers get paid is better for open-source. I think what the Devflight people are trying to do is admirable. I hope they succeed.
Also, I think that most people, who maintain decent OSS projects, have well-paying jobs anyways, so they don't need more money and more work to worry about. What they really need is pull requests and bug reports. Which the business can provide by _hiring_ people, who need money and work, to do the job and send the patches. Double benefit, everyone's happy.
> Maintainers experience pressure to continue developing their project to keep up with users, issues and feature requests. The more popular the project, the more value is being created on top of their software, and the higher the pressure. Because maintainers are often required to work on their projects in their spare time, working around a full-time job, it’s easy to burn out and stop working on the project altogether.
I've only seen people paid to work on the biggest projects, often only when it's become entrenched in everybody's workflow (Linux, some GCC developers, some Python devs), had the source code released after closed development (OpenSolaris, Firefox), or got taken over by corporation (Clang and Apple, khtml/webkit/Chromium with Google and Apple).
The vast majority of OSS projects IME are tiny, have few developers, and not many users outside of the developer.
I think you'd have a much better chance of getting open source maintainers' attention if they know more about what you do, your credentials, and how you approach working this out as a business. There's really nothing on the website!
might have made for a better introduction.
edit: I didnt mean this as a snark. I personally do not have 2 public projects where I'd feel comfortable to say "I'm developer/maintainer of X"
>> Thanks for that feedback. We start by collecting publicly available GitHub information related to the maintainer’s repo. This includes looking at who has engaged with projects by doing things like submitting issues, pull requests, and stars. We also use Twitter and any community channels the maintainer has created (Slack, Gitter, Discourse, etc.). Then we act as the maintainer’s sales team by reaching out to these leads with customized messages. We find the right people within an organization to discuss how the maintainer can add value to the company, and we negotiate contracts based on the custom plan we’ve developed with the maintainer.
