Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub stars won't pay your rent (2020)

kitze.io

Post reply on HN
Print view View original

121–130 of 251 posts

Re: GitHub stars won't pay your rent (2020)

#121

Post by pharmakom »

krasin wrote: post #107
Arnavion wrote: post #101

Earlier quoted context omitted.

>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.

>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought. You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By…

Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.

Re: GitHub stars won't pay your rent (2020)

#122

Post by jcparkyn »

bruce511 wrote: post #73
jcparkyn wrote: post #35

Earlier quoted context omitted.

I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects. I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of…

>> I'm not sure how I feel about this one. I think this may be a case where because you have a bunch of freedoms, you feel like you should have more. I say this to re-assure you, not critisize you. Open Source, and Free Software, are very clear on the 4 freedoms you enjoy. You can use, modify, distribute etc. But it's not a 2-way street. You have no rights about what goes back into the project, the author is under no…

I'm not saying I think the maintainers have any obligation to do things for me (I tried to make that clear in the original comment). What I was really trying to say is that I don't think this model would apply well to most projects, as the GP was saying.

To take an exaggerated example, if I tried to use this model with any of my small OSS side projects, the only result would be that no one would contribute. This model means that the development of the project is going to be almost entirely driven by:

a) The original maintainers of the project (who will rightfully get bored of maintaining it at some point), and

b) The handful of companies that have financial interest in a certain bug/feature.

Again, that's probably fine for projects like Fody, but certainly not all of OSS.

Re: GitHub stars won't pay your rent (2020)

#123

Post by krasin »

pharmakom wrote: post #121
krasin wrote: post #107

Earlier quoted context omitted.

>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought. You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By…

Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.

They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously).

The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.

Re: GitHub stars won't pay your rent (2020)

#124

Post by jcparkyn »

_carbyau_ wrote: post #30
nequo wrote: post #24

Earlier quoted context omitted.

> if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Maybe I’m misunderstanding but does this mean that you cannot submit a bug report unless you donate to them?

My reading of it on their page was that they are free to ignore your bug report unless you donate to them. You didn't pay? Well, that's just, like, your bug report, man... Essentially it boils down to: you cared enough to submit a bug report? Then you should also care enough to donate.

That logic (your last paragraph) essentially assumes that people only care for selfish reasons. Plenty of people contribute for the sake of giving back to the project (by e.g. taking the time to write a high-quality bug report or PR).

Re: GitHub stars won't pay your rent (2020)

#125

Post by ushakov »

viraptor wrote: post #67
zaik wrote: post #47

Earlier quoted context omitted.

A method to artificially pump up the GitHub star count will be found, but little useful software will be made.

Also the distribution of stars is... weird. I've got a repo with 24k stars (which is still enough for top 500 on github) which took minimal effort and no maintenance - definitely lower than a lot of large software projects which deserve lots of money. Like, I'm next to pipenv and vagrant and making any money distribution based on that would be absurd.

24k on GitHub, 32k on HN. You must be good at getting internet points

Re: GitHub stars won't pay your rent (2020)

#126

Post by ahepp »

pie_flavor wrote: post #20

I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a voluntary OpenCollective. And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. The result is a system that is paid enough to be excellent, excellent enough for most users not to need suppor…

I think the part of this that's weird to me, is that non-paying users are able to open issues or pull requests at all. Something about it feels very passive aggressive.

Why not just have the public facing project be a fork of a private, access protected project where bug tracking and PRs are handled, that only patrons can access?

For some reason, saying "only patrons can access our development repo" seems perfectly reasonable, but saying "we'll close your bug report if you don't pay us" feels a bit grumpy.

Re: GitHub stars won't pay your rent (2020)

#127

Post by jcparkyn »

thayne wrote: post #84
jcparkyn wrote: post #35

Earlier quoted context omitted.

I'm not sure how I feel about this one. Sure, the maintainers have no obligation to review and merge other people's PRs. But when this also applies to genuine high-quality community contributions, I feel like there must be some negative side effects. I'm sure this model works well for an established project like Fody that's already quite highly polished, but I'd be pretty sad if all (or even a significant subset) of…

There's an important qualification on that page: > This process will depend on the issue quality, and the impact on the larger user base. So, if I understand correctly, they won't automatically close issues if you aren't a subscriber, but the bar for the quality to keep it open is probably significantly higher. I don't think that's a bad model. Although, I don' think it would scale well to every open source project h…

Yeah that qualification helps a lot.

Re: GitHub stars won't pay your rent (2020)

#128

Post by ispo »

I believe the macro landscape (I refer to the end of cheap money) is creating a change of Paradigm that is being reflected on multiple angles in our circles and professional sectors. What I'm curious about is where is the line between the software that really should not be open because of its competitive advantage and the software that you can make open?

Re: GitHub stars won't pay your rent (2020)

#129

Post by hardwaresofton »

We just haven’t found the right business model.

I’m working on two things that will change that:

nimbusws.com (this is the moonshot —- a managed service/hosting provider that gives back to F/OSS. Imagine what would happen if a company 1% as big as AWS gave 30% back to F/OSS projects)

awsmfoss.com - A newsletter that features a new F/OSS project every day. 60%+ of recurring subscriptions are donated to F/OSS projects — only 2 paid subscribers right now but it’s a start. Things will get REALLY exciting once I build traffic and start donating ad revenue (probably via EthicalAds)

If either of these sound interesting to you (criticism, encouragement, requests to invest, want to be the first hire) email me victor@(either domain above) and we’ll chat.

Re: GitHub stars won't pay your rent (2020)

#130

Post by safety1st »

pie_flavor wrote: post #20

I continue to think that the best model is the one adopted by Fody.NET[0]. It's open-source, on GitHub, under the MIT license, developed in the open, and with a voluntary OpenCollective. And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. The result is a system that is paid enough to be excellent, excellent enough for most users not to need suppor…

While I'm always excited about new ways of monetizing open source, if I'm looking at the OpenCollective contribution page for Fody correctly, this model has made them under $10,000 in the past 2 years or so.

From a business perspective that's basically a rounding error and nothing compared to what you can do with the conventional approach of selling consulting/support or, heaven forbid, your own proprietary solution.

So in what sense is this the best model? Has anyone used it to generate $100,000 in annual revenue, let alone say $10M+? More profitable model = more hiring developers to improve the software...!

Post reply on HN