I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
The project managers also get a cut of all merges, testers also must approve of the merge and that feature X is the one they want. So the project manager gets to work and improve/reject features, the user gets control over the features of the project they want and developers get to pick specific features they would like to work on (sort of). everybody gets what they want (sort of). All via attaching $ to the issues of the software, not the people.
All we need to do is create Kalshi contracts! Users bet that a fix won't be created for Issue 123 by date XYZ, developers take the other side of the contract and then do the best kind of insider trading: changing the facts on the ground. We did it!
And a few weeks into that arbitrage traders will catch wind and start betting on the more likely bug closures and then the devs that fix the bug will end up owing money!
There are bribing and HFT opportunities here too. The fix developer is incentivized to wait until the last possible moment to take the position "the PR addressing the bug will be merged by the date" so that the contract will be the cheapest for them to buy and represent the greatest profit when the PR is opened or merged. What's a savvy speculator on the sidelines to do? After the PR is opened, bribe the project maintainer not to accept the PR by that date so they can turn a sure-thing "Yes" into a huge upset "No." Or watch the developer's github for green shower tiles to see activity in private repos. But the developer can throw up chaff that by scripting bunches of commits in other private repos, or changing the commit dates for the bug fixes to be a year ago. The speculator can monitor the developer's posts in language/topic forums or on social media to get a feel for their progress. If they're really connected, maybe they can see their AI agent/chatbot logs through an insider in one of those companies.
This idea rocks because eventually someone is going to get blackmailed with their affair history over, like, adding native XLSX support to FFMPEG. Can't wait. Financialize everything.
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
Have a bot on GitHub that nags people about the pool of committed money towards each feature, to show that they care about it - with the money being placed into an escrow and being released once the feature is implemented and merged, or until a date is reached with no merge and it's given back to everyone / or when the request is closed with no changes. Ofc no idea how you'd validate each individual issue well enough to prevent someone from misusing it, but one could feasibly create such a system, even if it'd probably get a lot of opposition from everyone.
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created
It might be good to have such a system as an option, but I wouldn't want it to become an expectation. I've got a couple of side projects that are out on GitHub. They have open source licenses and anyone is welcome to fork them, send bug reports, or pull requests, but I don't want to have any obligation of supporting those projects.
That's actually how a number of OSS projects work, we'll give you what we want for free but if you want us to do what you want you'll need to pay us. Having to implement a compatibility mechanism for some company's buggy train wreck from 20 years ago is a lot easier when you know you'll get paid at the end of it. A number of OSS dual licenses have been created to accommodate this.
You know what would be nice? For these billionaires to start sponsoring people instead of sitting on the obscene heaps of money they have—a patronage system. Everyone wins.
Are there any projects that have achieved anything close to this? I'm not against it in principle, but it seems like it ends up incurring issues from tiptoeing around wanting all the benefits of an incorporated business with employees or at least contractors without the stigma(?) of getting all official and putting someone in the hot seat of responsibility. Off the top of my head:
- A business has some intrinsic motivation however minuscule to fix unsexy issues like security problems or problems that aren't as visible to customers so they don't get hacked and sued and go under; in a pay-what-you-want bounty scheme all of your users are playing chicken to not be the one to put up the money for the fix. Instead they'll wait until it becomes a problem and fix it in their own branch; no reason to bother upstreaming it until someone comes forward putting up the money.
- IMO there's no way to measure cuts for something like this that can't be gamed. If you close out the bountied issue, but you make use of a bunch of utility code I contributed last week, who gets it? Or if the code I contributed is mostly a mechanical refactor of some very complex code someone else wrote? Do we divvy it up by lines of code, number of commits, etc, and that's just for the squint-and-it's-qualifiable metrics for engineers. No idea how you'd measure a cut for project managers. Someone also may be the steward of the repository and handle administrative work but not do a whole lot of feature-fixing, what cut do they get? Instead of juggling KPIs you can just pay all these people for their common contribution - time - and then you're back at something that businesses do really well.
- For any bounty system to work you need somewhere to track the bounties and hold money in escrow for payouts. Those services exist, they cost money to run, and they are going to take a cut. I'd assume they'd also invest and grow that money while they have it unless that's illegal for some reason I'm not aware of. An incorporated business keeps its bounties in the issue tracker, and its money in an account that accumulates interest that can go toward further development on the actual product instead of third-party support services. Crypto is a no-go here because that limits your contributor pool to exclusively crypto perverts, otherwise normal people have to speculate on it and convert it to normal useful money for a fee.
- I've worked at a place where the devs got to work on whatever they wanted. Required to, really, because there was very little interest or hands-on management from the owner in the direction of the product as long as sales were stable. We had a great time and got paid and we all learned a lot on company time and last I checked they are no longer in business.
- Timelines are a big factor too. If some open-source software I'm using is missing a big feature I'd like (and if post-2024, it's too substantial to just make a copy and have Copilot customize it for my use) I'm still not going to kick in the first $10 in the hopes that somebody someday builds that feature for me. I'm going to be dead or not using the software by then. If I thought the feature I wanted was worth $10,000 and I had $10,000 to kick towards it in the hopes that somebody somewhere would decide to build it, I would instead hire somebody on contract terms to do the work with a greater guarantee of results and some recourse if they screw me.
Those normal users are better off instead purchasing software. Then they will be listened to by developers if they report a bug or suggest a feature. Because they represent an incredibly valuable user segment: paying customers.
Users matter a ton to windows. Specifically, the users with a hundred thousand or more licenses. Their unhappiness threatens Windows' profits in a meaningful way. Why do you think all the new secure boot and TPM features were added to Windows 11? All that work wasn't free to implement. But big businesses really want that degree of secure fleet management, and they're the customers who matter.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
Large entities asked Microsoft to stop simply bundling Copilot with all those services and instead relabel the services so that their usage could be counted as AI usage in their quarterly report whether or not they actually engage with the AI features?
I think it's clear the source comment was referencing end users. It's patently obvious at this point that a large number of people who directly use Windows are frustrated with it, and perceive it to be degrading rather than improving over time.
A corporate end user isn't a customer. The customer is the corporate department of purchases. What I mean in my original comment is that if you as an end user purchase software, then you will be listened to by developers.
Most users of Windows get it for somewhere between free and $150, the fact that there is still a home edition of Windows is practically a loss leader to keep the business side ingrained. Enterprise licensees are the ones with the money and Microsoft will dedicate full-time engineers to their features if they can afford it.
The project managers also get a cut of all merges, testers also must approve of the merge and that feature X is the one they want. So the project manager gets to work and improve/reject features, the user gets control over the features of the project they want and developers get to pick specific features they would like to work on (sort of). everybody gets what they want (sort of). All via attaching $ to the issues of the software, not the people.