[karparov]

Sorry, that's a BS reason. If you don't want that, just ignore all opened issues. That's it. If you are nice then you put a README that explains this in a sentence or two. If a community forms that wants to fix issues, for example critical ones that could lead to data loss then the community will deal with it, e.g. by forking.

Just keeping everything closed is really missing the point of how trust in infra that handles critical data is built nowadays.

[notatallshaw]

As I understand it, from listening to the podcast, a better summary is that if it becomes popular, he wants it to be worthwhile for him to keep working on.

Apps like this can easily bit rot, and more users does often mean more work e.g. answering or filtering emails, finding more edge cases, etc.

From his perspective that means having a income to dedicate time to this. I don't think he's interested in being an "infra" app as you would think of it.

As someone who maintains critical open-source software, I can strongly empathize, even if it’s not an approach I would take.

[karparov]

I still maintain that if that's the case then something is wrong. More users reporting bugs for relevant edge cases is not a nuisance, it's the crowdsourcing of testing and each such reported issue is gold because then he can fix it before he as a user of his own software runs into it. Assuming he actually uses the software. (I also do maintain a bunch of packages and I do use them daily.)

Making software proprietary and for-pay, especially such a small tool, doesn't just significantly reduce the number of eyeballs this testing is crowdsourced to, but it also disincentivises issue reporting .. why should I spend the time to for free report sth to somebody who is making money off my testing and doesn't even bother to be transparent about how things work exactly (i.e. the source)?

If you really care about the quality of your work then maximizing the eye ball count and incentivise high qualith issue reporting.

Though if you want to maximize income instead, you keep it closed and ask for a subscription.

Quite obvious which option he chose.

[least]

> why should I spend the time to for free report sth to somebody who is making money off my testing and doesn't even bother to be transparent about how things work exactly (i.e. the source)?

You don’t have to. No one is saying you are compelled to report bugs in software you paid for. Most people don’t. The benefit to you as a customer is it can help get the bug fixed. That is clearly a mutual benefit.

> If you really care about the quality of your work then maximizing the eye ball count and incentivise high qualith issue reporting.

I think you’re vastly overestimating the value in the “higher quality” bug reports you’re getting from free users. You might get some higher quality reports but you’ll mostly get a lot more noise.

[cxr]

You're vastly overestimating how the norms of GitHub are able to account for how things have to be. Recognizing that GitHub's userbase has a certain type of problem is no different than realizing that HN, Reddit, Tumblr, etc. all have their own respective userbases and each tends to behave in certain ways (desirable or not) that are characteristic to that group.

[least]

It's not about the meta-characteristics of a user base. By allowing anyone to create issues, you are creating additional noise. Even if the signal to noise ratio were to be higher, you're still increasing total noise.

There are limits to how practical it is to allow for more and more feedback and that threshold for a solo developer is quite low. Restricting your user base by charging for your work means that there is less noise because the only people sending bug reports are paid users.

The quality of these reports are probably lower than if you had an open issue tracker, but you are substantially reducing the mental overhead and you know the people that are sending feedback are doing so with their own interests in mind.

[cxr]

At any given time when I'm at a restaurant or grocery store, there's more food around and on the menu than the threshold for how much food that I as a single person can eat.

[wubrr]

> As someone who maintains critical open-source software, I can strongly empathize, even if it’s not an approach I would take.

Pretty strange thing to say in the context of a closed source app.

[notatallshaw]

> Pretty strange thing to say in the context of a closed source app.

My intent was to express sympathy to making a closed source app instead of an open source one.

Something must have got lost in translation because it fits the context exactly.

[wubrr]

It doesn't add anything material to the discussion.

It's equivalent to saying 'I worked on a closed source project and liked it, therefore open source model sucks.'