I’ve also done both, and I found both kinds of users in both situations. There have been cases on the commercial front where I just felt like giving customers their money back, even after years of having used the software, and told them to not come back. There’s a lot of entitlement and craziness from paying users too, and those are harder to ignore. With open-source it’s much simpler to drive a hard line.
My “favourites” are the ones threatening to abandon the tool, despite having never made a single positive contribution. On open-source that’s an easy laugh and a “good riddance”. On commercial cases it’s more frustrating and nuanced.
I disagree willingness to pay is that meaningful of a filter, in the cases I experienced. And it’s getting worse; many people are getting too impatient and act like everyone works for them specifically and only their needs matter.
There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project. No cost to my volunteers either. The opposite is true in both cases; removing that user is a net benefit and I’ve done so in the past specifically to protect the experience of the volunteers.
As for tokens, there have been exactly zero cases where someone has submitted LLM code to one of my repos that has been up to my standards and I have accepted it. Yes, I can say that with certainty. If I wanted LLM code I’d ask for it myself, having an intermediary in that process is worse than useless.
> There’s no cost to me to stop an entitled disruptive user with zero positive contributions from destabilising the project.
Having to spend time reviewing a PR or issue is “no cost”?
I’m not convinced yet.
> As for tokens
I did not mean LLM contributions…I meant using AI tools to automate the reviews of contributions and users you seem to think cost no time or attention, but I do..
Yes, all of them if you want to. It's 100% up to you whether and how you deal with other people and their contributions, and it's completely orthogonal to being FLOSS or using a git hosting.
That's just one way to do it. Even if you let them send you PRs or whatever, you can still act on them or not depending on how they behave, your available resources, health, mood or just whim. You don't owe anyone anything and "creating a community around a project" is not a goal you have to be striving for regardless of whether you take contributions or provide some user support or not.
Finally!¹ My biggest use case is not actually creating passes for services which don’t provide them, but being able to create passes without having to install a freaking app.
FlixBus (I might be misremembering) is the only service I ever found which lets you pay with Apple Pay and add a pass to Wallet all from Safari. For airlines and other bus/train services I always have to install the app to do both. Maybe this will allow me to buy tickets on the web then make my own pass.
It feels wrong to say something nice about Ticketmaster, but you don't need their app to add concert tickets to Apple Wallet (at least at all the venues where I live). I strictly use their website because I don't trust them.
I've never tried to pay with Apple Pay on ticketmaster.com, but I assume I could do that as well.
This is getting stupid. Now one can’t even make a reasonable polite question with praise without being asked if they pay.
Bun raised millions of dollars and was acquired by a commercial entity which bragged in the same blog post of reaching $1B. They’re not a guy with an eyepatch and a tin can out on the street.
Open-source developers should be compensated, but they don’t have to be. You can’t reasonably offer your work for free then complain someone isn’t paying you. If you want to be paid, charge for it.
Signed: A long time open-source developer who has dedicated years of full-time work to useful projects without compensation or raising VC money or being acquired.
Come on, whenever a project is discussed on hackernews, there is always one comment of "why are you working on X, when you should be fixing bug Y?!".
We are all software engineers on here (or at least many of us are), we all know how project management and prioritisation works right? We can't work on everything all at once.
> Come on, whenever a project is discussed on hackernews, there is always one comment of "why are you working on X, when you should be fixing bug Y?!".
That is not what the question is about, which you’ll see if you engage with it properly in good faith. There is a single question in the comment (indicated, as one does in English, by a question mark):
> How do you feel about all the constant concerns being raised about the quality of the project lately?
Everything else is context and opinion to explain the question.
given the alleged context, X being something "reported in 2023, still affecting us 3 years later", is this not a reasonable PM / priority decision to question?
> I read somewhere (…) that software developers could be put into two camps (…)
Surely you read it more than once, because that has become a talking point. It’s a false dichotomy that, you’ll notice, is most often used by the people who put themselves in the first camp to steer the conversation. By framing it as “there are two camps, it’s just different, none of them is better”, it lends legitimacy to their position.
You don't have to pick one camp over the other. Good, high quality craft makes good products.
> after all, when did you see any members of the Enterprise writing code?
When did you see anyone in any media taking a dump, or sleeping, or doing any of the boring bits? Rarely, because if it’s not relevant to the story they don’t show it, but it doesn’t mean it didn’t happen.
I’m more of a DS9 fan, and I remember them having computer problems all the time. O’Brien, despite being highly competent and the chief of engineering with a team, was constantly overworked.
And their computers were infinitely superior to the LLMs we have now. When they gave you an answer, you could be confident it was correct. And if they didn’t know, they’d tell you!
I’d rather have a good browser which took its time to get things right than a speed run one.
Too much software is written like that, and the result is that most things are shit. What are we in such a hurry for? To get more time to work more? Fucking chill. Do things slowly and right.
As a side thought, speed running seems like the wrong analogy for software. Speed runners in games are people who spend a ton of time doing the exact same steps over and over to find tiny optimisations and develop muscle memory to do something repeatable. They take the time to do it well. Being a good speed runner means embracing slow progress. It’s the antithesis of software, where rushing to get it out also means you barely look at it. You do it fast but seldom right.
I think there's a balance to be struck between code quality and delivery speed.
GNU Hurd is a well known example where they spent a so much time on getting the code right that the project became irrelevant. And of course you made the case for erring on the "too much code too quickly" side
The comment I responded to talked of “speedrun” and “full speed ahead”. That’s the antithesis of balance.
The point you’re making is valid but has no bearing on the current conversation. GNU Hurd is also an extreme case, the overwhelming majority of software suffers more from being rushed than from being so slow it becomes irrelevant.
Your argument is so removed from the point, it’s an entirely different conversation.
I already contribute time and code to open source projects, and I promise you’ll have heard of some of the things I contributed a lot to. That’s beside the point.
This is like saying “I’d prefer if doctors took their time with patients to understand their cases and provide meaningful accurate resolutions to ailments instead of rushing” and you replying with ”oh yeah, are you willing to contribute with medicine and triage?”.
It didn’t go nowhere; a few projects implemented it. The philosophical basis was wrong, though.
Opt out should not be encouraged via an off switch. It should be eradicated, and the people who accepted money to write such malware should be plainly named so that such actions can be part of their professional reputation.
> It didn’t go nowhere; a few projects implemented it.
If you try to create a standard and almost no one implements it, it’s not a standard and it went nowhere. Its stated goal wasn’t achieved, and the fact its domain and webpage have been abandoned makes that abundantly clear.
From the top of my head, unlocking the keychain, finding the right identity, notarizing two parts, the binary itself and the .dmg that the .app ships in and some other stuff I'm sure. Can do a deeper look in a bit when I can. Most of the hassle is because it's 100% unattended and I had to do stuff to avoid GUI-prompts for passwords/unlocks, and that the Forgejo Runner has a different security context.
This matches my experience. Keychain + fully unattended increases the complexity and adds a bunch of landmines that need to be dodged (e.g. GUI prompts like you mentioned).
> unlocking the keychain, finding the right identity
You don’t need to do that, you can give options to the CLI to define what profile to use.
> Most of the hassle is because it's 100% unattended and I had to do stuff to avoid GUI-prompts for passwords/unlocks
I have a shell function to which I point my code and it compiles, signs, and notarises it without any more intervention, GUI or password prompts, and I’m pretty sure signing and notarising are literally two lines.
Unfortunately I’m not at my computer now or I’d paste them, but from your description that script is definitely too long.
My “favourites” are the ones threatening to abandon the tool, despite having never made a single positive contribution. On open-source that’s an easy laugh and a “good riddance”. On commercial cases it’s more frustrating and nuanced.
I disagree willingness to pay is that meaningful of a filter, in the cases I experienced. And it’s getting worse; many people are getting too impatient and act like everyone works for them specifically and only their needs matter.
reply