Live data from Hacker News

Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money

news.ycombinator.com

61–65 of 65 posts

Re: Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money

#61
post #19

Earlier quoted context omitted.

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

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.

Re: Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money

#63

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!

Thanks for sharing @andy_adams! Henry here, happy to chat with y'all (Victor and Tony) if you'd want

Re: Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money

#64

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 maintainer…

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.

Re: Launch HN: DevFlight (YC W19) – Helping open-source maintainers make money

#65
post #44

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 g…

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.

Post reply on HN