Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money
64 comments
I really like this idea.
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.
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.
"Companies often aren’t aware of all the open-source software they’re dependent on".
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.
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.
We'll definitely check them out. Thanks for the suggestion!
For anyone interested in the difficulty in maintaining huge OSS projects, I found this episode of ShopTalkShow with Henry Zhu (maintainer of Babel.js) fascinating:
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!
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!
It looks like DevFlight's focus is on identifying active revenue streams for maintainers, based on whatever aspects the maintainer is flexible in commercializing (priority support, feature requests, etc). That's an awesome way to help create revenue without splitting the maintainers' attention between sales and the project.
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
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
I also like that DevFlight works with individual maintainers, rather than with projects. Many prolific maintainers work with several projects. They may not have created any of those projects, and they may not run them either. When the spotlight is on the project (and by extension the founders of "top dogs" of that project), those valuable maintainers get ignored. I'm glad DevFlight is focusing on the individual.
I don't disagree that finding ways for prolific open source contributors to be able to monetize their expertise is incredibly valuable, but I'm not sure if that's actually DevFlight's focus.
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. :)
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. :)
Great question. At this point, we’re focused on partnering with core maintainers of a project. As you’ve stated, these are the individuals who have control over what gets implemented in a project and ensuring project stability. However, we are also exploring ways to get expert contributors involved in the future.
Great business model, great cause. I really hope you get successful.
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.
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.
Do you have an idea about the size of your target market?
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?
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?
Thanks for your questions. There are no project requirements to join the waitlist. Right now we’re working with maintainers of more popular projects. We’re measuring popularity in terms of users. We expect maintainers to be able to replace their current full-time salary if they want to work on their projects full-time. Some maintainers only want to allocate a percentage of their time to open-source, so the expectations for how much money they can make are different in those cases.
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.
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.
Check out https://tidelift.com if you’re interested in something more robust that won’t take 10%. A bunch of ex-Red Hat guys who are truly open source legends behind it.
Have you used them? What's their cut?
They're not about "cuts." First they track probably hundreds of thousands of packages/projects. They set up a subscription model where they charge based on dev team size/org size and project utilization and they provide security updates, maintenance, and legal assurances for the open source projects being used. Maintainers who sign up to help "lift" sign on for certain amount based on the popularity/ubiquity of the project. They are essentially channeling the revenues from these companies and paying out the maintainers. It the same as Red Hat charging a subscription fee and providing a whole bunch of stuff around that but Tidelift is paying maintainers directly.
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.
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.
[deleted]
Thanks for your comment. We have a lot of respect for anyone working to make open-source more sustainable. Here’s more information from their pricing page (https://tidelift.com/docs/lifting/paying)
> 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.
> 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.
My name’s Victor and I’m one of the DevFlight founders. Tony and I are here to answer any questions you have. We’re very excited to have the opportunity to collaborate with the HN community.
I really like the idea, and appreciate that there are people out there trying to solve this problem! I have struggled to financially support my open source projects through donations and support contracts, and ultimately decided on an open core model, which has yielded the most success to date. Moving to an open core model is challenging and building out a sales process and sales team can be a barrier for many developers. I was wondering if you have considered including something like reselling, for lack of a better word, in your offering. Having someone negotiate a variety of monetization options on behalf of the project, including selling licenses, would be very interesting. (note I acknowledge open core is not open source, and therefore may be contrary to the goals of this startup).
We really appreciate your support! Yes, we’ve discussed something exactly like what you’re describing here. Open-core is an important revenue stream for open-source projects. We’re carefully considering how we can support projects that best fit an open-core model. I’m curious to hear more about the challenges around that shift towards an open-core model.
thanks for the response. I will add my name to the waitlist and look forward to discussing at a future date.
I don't want to sound pessimistic, but I think that only a few percentages of OS projects are worth any kind of money to pay for.
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.
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.
There’s a bit of a chicken and egg problem with that; basically you’re requiring someone to build and grow the community for free for years until it gets “big and crucial” before paying them, by which time they may well have burned out and moved on.
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 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 like the ideal. Something certainly needs to be done.
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'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.
This is an interesting idea. Making open-source more sustainable definitely requires an aggregation of resources. I think something like what you’re describing would help make it easier for maintainers to collect donations, and for more people to give them, so it would be worth exploring.
I think also, in a good way, it might actually cut down on forks and "splinter" projects. That is, ideally, someone would be more likely to stay and contribute if they know there is revenue to be share with them (as opposed to starting from zero).
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.
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.
Can you share publicly any of the projects & maintainers you're currently working with?
Co-founder here. Absolutely! We’re working with the wonderful maintainers of projects like Caddy Server (https://github.com/mholt/caddy) and OctoberCMS (https://github.com/octobercms/october). We’ll be able to share more of the maintainers we’re partnering with soon.
Funny to see caddy here, since they are already offering commercial licenses.
EDIT: In fact, commercial use is only available via the commercial license, even if a company decides to build their own binaries.
EDIT: In fact, commercial use is only available via the commercial license, even if a company decides to build their own binaries.
One nice thing about free OSS is that it's not paid for. Hence, less influence by external forces, fewer obligations, no strict deadlines, etc. More often than not, this leads to better quality of such software (given that maintainers are experienced and smart). I'm not sure how establishing a direct relationship between money and work (as opposed to donations and grants) would affect the rather high standards of good OSS..
I would imagine that the vast majority of free/OSS is done as paid employment.
Do you have anything to back that up, because it directly contradicts my experience.
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'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.
> Do you have anything to back that up
Have you read Berdou's PhD research on the topic?
http://www.lse.ac.uk/media@lse/study/pdf/PhD_Berdou_2007.pdf
Paid developers are more likely to maintain critical parts of open source code bases.
Have you read Berdou's PhD research on the topic?
http://www.lse.ac.uk/media@lse/study/pdf/PhD_Berdou_2007.pdf
Paid developers are more likely to maintain critical parts of open source code bases.
I had not, but it seems to back up my point.
From the Overview section: "F/OS software is developed by online communities of globally distributed contributors, the majority of whom are volunteers who rarely meet face to face."
And it uses KDE and GNOME as case studies, which are both very large, entrenched projects that are subsidized by companies like Red Hat and Canonical.
What I'm getting at, though, is that if you pick 1000 arbitrary repos on GitHub (or BitBucket or GitLab), 999 of them are not going to have any paid contributors. Once you start filtering by user and/or contributor counts you're removing a large amount of projects that aren't popular, but never the less count as open source projects.
From the Overview section: "F/OS software is developed by online communities of globally distributed contributors, the majority of whom are volunteers who rarely meet face to face."
And it uses KDE and GNOME as case studies, which are both very large, entrenched projects that are subsidized by companies like Red Hat and Canonical.
What I'm getting at, though, is that if you pick 1000 arbitrary repos on GitHub (or BitBucket or GitLab), 999 of them are not going to have any paid contributors. Once you start filtering by user and/or contributor counts you're removing a large amount of projects that aren't popular, but never the less count as open source projects.
That's the majority of people, not the majority of the work. I said majority of the work. The PhD supports my assertion that the majority of the actual work is done paid.
I don't believe you for your 999 out of 1000 repos, but I'm not sure how we'd check that. When I browse people's GitHub profiles it's almost all little forks of things they're clearly using in their work.
I don't know what people think OSS is - it's not hobbies. The majority of our infrastructure is OSS - operating systems, compilers, browsers, virtual machines, tools, it's almost all OSS and all majority paid contributors.
I don't believe you for your 999 out of 1000 repos, but I'm not sure how we'd check that. When I browse people's GitHub profiles it's almost all little forks of things they're clearly using in their work.
I don't know what people think OSS is - it's not hobbies. The majority of our infrastructure is OSS - operating systems, compilers, browsers, virtual machines, tools, it's almost all OSS and all majority paid contributors.
> That's the majority of people, not the majority of the work. I said majority of the work. The PhD supports my assertion that the majority of the actual work is done paid.
The PhD supports that the majority of work on KDE and Gnome are done paid. Those are not typical examples, though, and I don't believe the conclusions apply to OSS in general.
Projects like those make up a tiny percentage of the OSS ecosystem, whether measuring by people or by work.
The PhD supports that the majority of work on KDE and Gnome are done paid. Those are not typical examples, though, and I don't believe the conclusions apply to OSS in general.
Projects like those make up a tiny percentage of the OSS ecosystem, whether measuring by people or by work.
Great if so. Writing OSS as part of the job is actually a good thing, because (1) there's a relatively stable entity that is responsible for this software at the end of the day (and not a single proud and starving artist, who may get ill, get married, get another project, etc.) and (2) someone actually has a _real job_
That is a naive thing to say. Open-source work doesn’t become purer when underpaid. Making open-source pay better for everyone, not just a privileged few, will allow more people to join the open-source movement, raising the standard of software quality for everyone.
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.
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.
Everyone who? It's highly unlikely that companies will pay an awful lot of money to these maintainers anyways, so only the less "priviled" (i.e. second/third world citizens mostly) will benefit. Moreover, while some individual maintainers will gain in short term, the developers as a workforce will definitely lose (because certain tasks are taken from freelancers, contract workers and employees and distributed to, well, public). Business does not need more developers (let alone better paid ones), it needs more work done faster and for less money.
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.
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.
Can I ask. Do you write or maintain OSS code? Do you have large number of users? Do you work full time on OSS? Because your opinions are incredibly naive.
That's completely irrelevant. Working full time on OSS means being a businessman in disguise (and, arguably, perverts the very ideas of free OSS), so we're on the opposite sides of the fence, I presume. Or do you live off something else and work on your projects completely out of sheer altruism?
As someone who has worked many years in open-source, including as a maintainer, I can confirm that you clearly have no clue what you’re talking about. Your argument that somehow, not being paid for our work makes that work better, is 1) idiotic, 2) disrespectful, and 3) damaging to everyone trying to actually contribute. Arguments like yours are exactly what is wrong with open-source today. I’m glad this ridiculous mythology that you’re perpetuating is being challenged by the new generation of maintainers. But by all means, stay on your “side” of the “fence” as you put it. The open-source community has no use for you or your outdated ideas.
This is a fascinating point. I absolutely agree that injecting money into software can have unintended consequences. After speaking with a lot of maintainers, one common theme is that the widespread commercial use of open-source software has already created this direct link between money and work. 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. We’re using this contract route as a way to make open-source sustainable for maintainers and establish clear expectations for both maintainers and companies. Setting those expectations is key to giving maintainers their ideal work scenario where they won’t have to sacrifice quality for speed.
Exactly this:
> 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.
> 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.
Thank you for the reply. Let me ask you, why premium is fixed at 10%? As I see it, this would make sense only for large quantities of small payments. I.e. it seems like you're expecting exactly what you say you're hoping to eliminate: small feature requests, bugfixes, maybe some integration tasks, docs, etc. How about yearly support contracts?
One of us misunderstood what they do. The way I read it was that they establish a contract between dev and corp with regular payments (of which they take 10%), in exchange for this the corp gets the things listed above like prioritized bug reports and so on. But they don't pay for the single bug fixes or anything.
Your point about donations and grants is a good one. Working with us does not mean maintainers have to exclusively use contracts to make money. Making open-source more sustainable will definitely require an aggregation of resources. We’ve learned from maintainers that donations can also have unintended consequences and create certain levels of expectations from the individuals and companies that make them. However, for some projects the donation model can work well, so we definitely encourage maintainers to also accept donations in these situations. Vue.js is a perfect example (https://vuejs.org/).
[deleted]
I'd like to know some more about how exactly you go about executing the plan? The landing page doesn't go into any detail there.
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!
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!
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.
I love the idea of it but as a company why tf would I ever go " yea ill pay for something i get for free now " when if i need their code based maintained i just pay my existing developers.
Thanks for the question! Many companies are already paying or willing to pay for open-source software, especially when a lot of their critical infrastructure in production is open-source. This is becoming a more common occurrence as open-source rises in popularity. In many cases it’s cheaper and faster for a company to pay expert maintainers rather than hire more developers or get their current developers up to speed (and keep them up to speed) on the open-source software they use.
[deleted]
"We’re Victor and Tony, maintainers/developers of $PKG1 and $PKG2, and now founders of DevFlight."
might have made for a better introduction.
might have made for a better introduction.
That requires 2 other projects though
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"
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"
Good initiative, how does sales work - what part of it is automated and what is run by sales team ?
Seeing this has been answered in one of the below threads. Got it.
>> 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.
>> 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.
Is there a way for companies to pay maintainers in exchange of some kind of promotion? Like logo in readme or something like that?
https://tidelift.com is doing something similar.
Have you guys looked at the tidelift model in comparison?
Would love to hear thoughts there.
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