
Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money - vbordo
Hey HN,<p>We’re Victor and Tony, founders of DevFlight (<a href="https:&#x2F;&#x2F;devflight.com" rel="nofollow">https:&#x2F;&#x2F;devflight.com</a>). We help open-source maintainers make money. Think of us as agents for open-source maintainers.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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!<p>Victor and Tony
======
henvic
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.

------
oliverx0
"Companies often aren’t aware of all the open-source software they’re
dependent on".

Gitlinks
([https://www.youtube.com/watch?v=VdaQE6FpM_Q](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.

~~~
vbordo
We'll definitely check them out. Thanks for the suggestion!

------
andy_adams
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/](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!

~~~
tmastro
Very fascinating, I will definitely listen to this. Thanks for sharing!

------
cosmie
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](https://www.irs.gov/pub/irs-pdf/p598.pdf)

~~~
zapita
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.

~~~
cosmie
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. :)

~~~
tmastro
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.

------
nojvek
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.

------
jlarocco
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?

~~~
vbordo
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.

------
jaboutboul
Check out [https://tidelift.com](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.

~~~
riyakhanna1983
Have you used them? What's their cut?

~~~
jaboutboul
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](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](https://tidelift.com/about/lifter)

 __I DO NOT WORK FOR THEM. Just think this is the future of sustainable open
source.

------
vbordo
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.

------
bradrydzewski
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).

~~~
vbordo
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.

~~~
bradrydzewski
thanks for the response. I will add my name to the waitlist and look forward
to discussing at a future date.

------
wrestlerman
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.

~~~
BenjieGillam
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.

------
chiefalchemist
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.

~~~
tmastro
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.

~~~
chiefalchemist
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.

------
jmwilson
Can you share publicly any of the projects & maintainers you're currently
working with?

~~~
tmastro
Co-founder here. Absolutely! We’re working with the wonderful maintainers of
projects like Caddy Server
([https://github.com/mholt/caddy](https://github.com/mholt/caddy)) and
OctoberCMS
([https://github.com/octobercms/october](https://github.com/octobercms/october)).
We’ll be able to share more of the maintainers we’re partnering with soon.

~~~
dotdi
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.

~~~
detaro
> _even if a company decides to build their own binaries._

Huh? It's Apache 2, how are you prevented from using your own binaries?

------
atomashpolskiy
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..

~~~
vbordo
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.

~~~
atomashpolskiy
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?

~~~
Semaphor
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.

------
Malfunction92
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!

~~~
tmastro
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.

------
zackj117
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.

~~~
tmastro
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.

------
craigsmansion
"We’re Victor and Tony, _maintainers /developers of $PKG1 and $PKG2_, and now
founders of DevFlight."

might have made for a better introduction.

~~~
thecatspaw
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"

------
samblr
Good initiative, how does sales work - what part of it is automated and what
is run by sales team ?

~~~
samblr
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.

------
ajimix
Is there a way for companies to pay maintainers in exchange of some kind of
promotion? Like logo in readme or something like that?

------
Edmond
[https://tidelift.com](https://tidelift.com) is doing something similar.

------
agibsonccc
Have you guys looked at the tidelift model in comparison? Would love to hear
thoughts there.

