Long time ago Sourceforge and then GitHub promoted into the current default the model of open source distribution which is not sustainable and I doubt it is something that the founding fathers of Free Software/Open Source had in mind. Open source licenses are about freedom of using and modifying software. The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user to better fit the user's needs. To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all. The currently default model of having an open issue tracker, accepting third party pull requests, doing code reviews, providing support by email or chat, timely security patches etc, has nothing to do with open source and is not sustainable. This is OK if it is done for a hobby project as long as the author is having fun doing this work, but as soon as the software is used for commercial, production critical systems, the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane. This is software support, it is a job, it should be paid.
Years ago, I built what I thought was a pretty basic static site generator using HapiJS. I was using it for personal projects and after some convincing by friends, put it up on Github. My friends went on Reddit and posted it and then told me about it afterwards.
It initially got some decent traction and then all of a sudden, all the pull requests came, all the feature requests and then all the bug reports.
I kept telling people this was a side project, if they want to fork it go ahead, but this is not something I'm going to spend a ton of time on. Then all the hate started about how I put something out into the OSS community with no desire to support it. I was bad person, my code was shit and I should stop being a developer.
That was my first and last OSS project.
I applaud and respect the people who are committed to getting OSS out there, but for me, it was a horrible experience.
Bitching is free and easier than making pull requests. And I bet it was 1 or 2 choads plus a variable pack of minions, not everyone. And Megacorp X can file all the bug reports they want, their lack of investment is not my urgency.
In general, there is a difference of ethos and culture between Free Software and Open Source movements. GitHub is the latter: strewn with expectations from low-effort requests.
With free software, many projects have their own code hosting with separate accounts, sometimes even separate bug trackers with another set of accounts (think Bugzilla + GitLab). Any submission is by definition bigger effort, and thus the culture is significantly different.
As an example, just try submitting a patch to GNU libc (if it hasn't switched to GitHub in the intervening years, though I'd be surprised as it's a GNU project, but it's also largely supported by Red Hat), and see where you get to. Or join the GNOME community and submit a fix. Or FreeDesktop. Or KDE. Or...
If you allow me to go on a meandering tangent/exploration:
___
I mean if you think about it, this outcome is more or less inevitable, given the environment we've created.
The foundational building block being that people will always optimize for their own benefit and personal gain. They fundamentally have to, because no one else will.
So that gives us a natural source of conflict, because not everyone is a builder (or at least not everyone believes that they would), meaning that they need to get someone else to do what they want to get done.
You as a builder of course operate no different to that. You also want to optimize for your own personal gain.
Where it is different though is that you do not rely that much on external resources to do that, given that you can create by your own.
So these are our building blocks.
To have a functioning societal system, we do want and need to allow people that don't to receive a decent-ish slice of the output of those that create for various reasons.
Something something shared humanity, but also the fact that a society built out of autonomous builders quickly collapses. Plus multi-dimensionality, meaning that person A might be a builder in discipline X, but needs others to sustain themself in discipline Y. Society and all. Shared workload.
The mechanism that regulates the flow of resources between these agents is friction.
For example, social shaming for not sharing the fair part of what you're earning is friction. That is a constant eroding force and cost that is supposed to shift your internal mental calculus to make contributing to society the most sensible outcome.
Equally so, the act of being protective of your time, demanding respect, boundaries and fair compensation is friction that is supposed to shift someone else's mental calculus to make fair treatment of you the most sensible outcome.
____
Okay, many words, but what the fuck am I on about?
Here's where this self-regulating system implodes:
In the last two decades or so, we have absolutely supercharged the mechanism of shaming and public pressure (rel: Twitter).
Simultaneously though, we've also _vastly_ nerfed any forms of friction a builder might employ. (rel: GitHub as the default, being "nice and professional" as the default, etc.)
And that is what simply is not working.
But we're not talking about that properly, because any platforms we currently have for talking about stuff are absolutely and utterly dominated by those that do not create; meaning that they get to dictate the rules.
In a very unsustainable way of course (see also collapse of democracy in general) but that is still the reality we find us in.
___
And that is _I think_ also where we can find solutions to these problems.
Don't get me wrong, I'm not proposing to return to linus and tell people that they should be retroactively aborted for having made a mistake.
There were many very important advancements we made culturally to push out toxicity.
We will need to reintroduce friction though.
Likewise, we will need re-engineer our communication spaces to shift the balance of power back to a sustainable equilibrium.
Which doesn't mean "cold uncaring meritocracy" (also, what even is merit?) but it will mean not handing out ever-larger megaphones based on who is already screaming the loudest.
___
Anyway, TL;DR:
It's the system, stupid. It is like this, because it can't be any else given the currently governing rules.
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.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
Free Software sure, that wasn't the point.
Open Source, that was exactly the point. Eric S Raymond, one of the original promoters of the concept of Open Source coined Linus' Law:
Given enough eyeballs, all bugs are shallow
Which definitely points in the direction of receiving bug reports and patches from users of the application. He was also a proponent of the Bazaar model, where software is developed in public, as opposed to the Cathedral model where software is only released in milestones (he used GCC and Emacs as examples, which reinforces the part of your statement about the Free Software movement in particular).
ESR is also from a time where spamming countless reports/junk code wasn't really a concept.
They did have things like trolls and zealots that thought "Their one idea" was a gift from god and the maintainers were idiots for not adding it to the application. And eventually those people may have been banned from mailing lists. But in general the people posting code were typically well known and had some interest in fixing the application for some useful purpose.
Simply put, no idealism stands the test of time without change. Nature shows us that everything must evolve or it goes extinct. How 'free software' evolves is now up for debate.
Linus’ Law doesn’t really imply anything about maintainers behavior though. As an example, you can imagine maintainers that never update their repos. Every bug fix is a forking of the repo, and people only use the repo with the latest commits. Eventually, the bug count goes down as well!
I don’t agree with this newer idea that has arisen that FOSS authors are “victims.”
It’s up to you to set boundaries (or prices) and communicate them, like an adult. If one is still rude and entitled then ban them from the repo, or let people fork, but not before looking in the mirror first and reflecting at your own behavior.
(I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.)
As always it depends on the circumstances, but should default to quietly closing with WONTFIX. Others have said Daniel is typically helpful and respectful so there we go.
What you linked to is not really evidence, just an unsubstantiated allegation. Over the top public shaming is something that should be pretty easy to provide direct evidence of. When Linus Torvalds does it, it gets repeatedly brought up in forums like this for many years.
> I have no reason to believe it is a lie, and it sounds plausible
Except for all of the responses from people saying it doesn't sound plausible for the project in question, and for the acute lack of real evidence or even details to accompany the allegation.
Additionally, I think "last resort" is way too high a bar. It's totally reasonable for an open source project to have a zero-tolerance policy for AI-generated spam patches or bug reports, and to respond with public shaming after the first offense. Nobody should be expected to make any allowance for such egregious behavior.
A user who is genuine but simply doesn't know how to usefully communicate about their problem doesn't deserve that treatment and should simply be ignored if the devs don't have time to engage in the interrogation necessary to extract a useful bug report. But if the user decides to try to use an LLM to compensate for a lack of content in their bug report, that user would be earning a negative response by making a bad decision. (If you're going to use an LLM, ask it how to write a bug report, rather than asking it to make up a bug report for you.)
Afaict github allows you to disable 'Issues' per repo, yet few do. I presume that means they are okay engaging with issues on some level, but I find it odd almost none post a policy/expectations around them.
> I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.
... Did they try anything as petty as the xorg maintainers are nowadays?
Sourceforge is almost 30 years old. GitHub almost 20.
How long does something have to be done a certain way for it to be "to do with"?
I would say we're now two generations deep of software engineers who came up with open source software commonly being mediated through public issue trackers.
That isn't to say it needs to stay that way, just that I think a lot of people do in fact associate public project tracking with open source software.
I partially disagree. It does have to do with open source: Github (et al) are about creating a community around an open source project. It's hard to get adoption without a community; it gives you valid bug reports, use cases you didn't think of, and patches.
You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
> and is not sustainable
I 100% agree. People (including people at for profit companies) are taking advantage of the communities that open source maintainers are trying to build and manipulating guilt and a sense of duty to get their way.
The most insidious burnout I see is in disorganized volunteer communities. A volunteer is praised for jumping in with both feet, pushes themselves really hard, is rewarded vocally and often and with more authority, and is often the one applying the most pressure to themselves. There's no supervisor to tell them to pace themselves. And when their view switches from idealistic to realistic and then falls into pessimistic, they view the environment through a toxic lens.
> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
Literally you cannot, you can turn off "Issues", but you cannot turn of pull requests, Microsoft/GitHub forces you to leave that open for others to submit PRs to your repositories no matter what you want.
Yea, and before we got issue trackers quite commonly issues and code chunks were shared via email lists that quite commonly had online archives. Think things kind of like the LKML.
I thought about this a lot recently and decided that the small, mostly complete, project I work on now, if I release it (I probably will), I will just post an archive somewhere with the source code, like in old days.
I kind of do that already with my most recent project, developing it in my local fossil repo and each release I have a script that copies it to a local git-repo, tags it, and pushes it to GitHub. So the GitHub history just has a series of release commits.
But the project is still open for issues and PRs. Can only be disabled on paid accounts, right? Never had anyone try yet. I had feedback through other channels, just not on GitHub, so maybe explicitly keeping all development offline has had the intended effect? I get a trickle of issues and PRs for my other repos where development is out in the open with every commit pushed to GitHub.
But if it was discovered by drive-by LLM contributors I would still have annoying extra work, for no obvious benefit compared to just sharing archives. I do not think anyone (out of at least dozens) discovering any of my repos do that on GitHub, but from seeing my posts elsewhere.
It's not like no one can fork a source code archive, even if it is like 3-4 git-commands to run instead of just a button to click.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
From the beginning, GNU projects welcomed contributions, and discussions of bugs and features were in the public. Sure it was on mailing lists, not on Github, but it was more than just shipping sources with the binaries.
That isn't to say you have to accept third party pull requests and have an open bug tracker to be free software/open source. Sqlite is a famous example that doesn't follow that model.
I dunno, I think at one point there was a similar merge as to what happened with "git and "github" where "open source the licensing" somehow became the same as "open source the collaborative and open software development process", and nowadays people get kind of confused when you say you're doing open source yet you don't accept pull/merge requests.
Maybe WTFPL can send the message across? Could maybe make a V3 and add as a second point to it: "1. And don't tell me/ask me about it, just DO WHAT THE FUCK YOU WANT TO"
> the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane.
I think there are many insane expectations out there, open source or not, so I don't personally see it that linked with the idea/ideal of open source.
> This is software support, it is a job, it should be paid.
Anything can be paid, nobody says otherwise. Some people prefer nobody pays for their source code (open source). Other people do support for free. And so on.
> The currently default model of having ... has nothing to do with open source and is not sustainable.
There were always arguments why open source will not be sustainable, many having some truth in them. But the current issue can be probably solved with some push-back on the speed of things or how attribution works. Something similar used to happen on some forums: you can't post a new thread for one month if you did not reply at least once without getting down-voted. For the current problem : if contributions are anonymous for the first 3 years of you contributing (if you are not banned) and your name becomes public only after, then all this "noise" for "advertisement" will die. Doubt this will discourage any well intentioned contributor.
Irrelevance. The moment you paywall a project, it’s a death sentence. Unless you have a unique and highly sought-after product (top 1%), someone else will just make a free alternative.
Well yes, but that accomplishes the goal of not working for free. Either you get money for your work, or your users move on, freeing you of the burden of supporting the software.
Exactly, that's an example of a top 1% project. It even has a detailed Wikipedia article in 35 languages. That model won't fly with small to medium-sized, regular projects.
If you have just thrown the code out there, in case someone can use it, then who cares? If it's not something you intend to spend more time on, what difference does it make?
Totally agree. The expectations around what an OSS project should - or even must - have, do, and accommodate is absolutely insane. It boggles my mind sometimes as someone who grew up on OSS. I still contribute OSS and maintain some (small) projects, but I certainly don't feel compelled to support people. I often license MIT. People are grown ups, they can go fix their own issues.
You mischaracterize the problem. You write like the problem would be corporate freeloaders forcing bug fixes on the open source.
Huge problem for successful OSS projects is like what we have for cURL right here - newbies trying to "earn badge of honor" for scoring CVE on high profile project. The variation of it is newbies trying to score OSS contribution on high profile project (hacktoberfest).
In the end all of it is propping own CV to land a software engineering job or cybersecurity job by wannabes.
As much as I don't want to do gatekeeping and especially "old" Linus Torvalds way of gatekeeping — cURL, Linux Kernel and many high profile projects require gatekeeping to go on forward. We didn't even start on the security side of things not to allow "shady contributors".
I hate "CV proppers", "OSS as great marketing tool", "corporate freeloaders", "APT threat actors using OSS as attack vector" because they break nice things that we could have.
The original model works, the new model significantly fails. LLMs have taken many cases that were on the border over the line into failure, by changing the resource management tradeoffs. (Both by giving valuable contributors a cheap way to get 'extra eyes' on their own terms, and by empowering a new generation of trisectors and trolls to flood out even the most efficient public submission pipelines).
Technically correct, but not an issue in practice. If you want a licence that's approved by the OSI but not the FSF, or vice versa, you have to go looking for it. If memory serves there are no licences in the latter category, and the few in the former category are very obscure.
> This is software support, it is a job, it should be paid.
It is paid, even if not in money. It seems like maybe you lack awareness of the other forms of capital and reward that exist, because your framing implicitly insists that financial capital is the only form of capital and that monetary reward is the only form of reward. But there are also a bunch of other forms of capital, like social, cultural, symbolic, etc. which you have missed, and there are non-capital (non-convertible) forms of reward, like feeling good about something. It's the entire reason why permissive licenses still preserve attribution.
To wit, people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things. There are both intrinsic and extrinsic non-monetary gains here.
Stallman makes the same critical error in his foundational writings, so at least you're not alone in this.
>people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things.
True, but the expectation means that taking on maintenance involves taking on and leveraging a large amount of reputational debt in a very risky way.
If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
It is incontrovertible that the entirety of the open source / free software world exists, in a very fundamental way, because people experience personal reward by doing work that they give away for zero dollars.
The existence of risk does not eliminate the existence of reward. It's called "expected value", and it's non-zero, and it's for the person to manage for themself like everything else in life. Working for equity also involves risk, and nobody says that it's not compensation.
> If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
This is like saying you suffer reputational damage by retiring from a career. The claim is clearly absurd. It's not hard to step down from leading a project in a way that preserves reputation in the same way that it's not hard to leave a company without burning bridges. Some people are bad at being people and fail at both.
My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own, and that one of the reasons for that is the risk that stems from stepping down being something that you can fail at in the first place, with the consequences of cementing a reputation of "being bad at being a person" regardless of anything that's happened to that point. You don't have the opportunity of accumulating reputation without having that risk at the end, unlike a career, where you have the opportunity of taking a job that pays a regular paycheck regardless of whether you leave at the drop of a hat and burn all your bridges by doing so.
> My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own
OP said "it should be paid" because "it is a job", and so the rejection of that claim is two-fold: 1) Uncertainty in the expected value of payment does not change the fact that it's payment, 2) Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
OP's specific written framing, that because it's a job it needs to be paid, which is only additive commentary if OP believes that it isn't being paid, disagrees with your prediction about what OP really secretly bases their statement on.
We can look further back in OP's comment as well:
> The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user
This is only fractionally true, and it is only true in an unpaid way for a desire to consume free software. It is not true in an unpaid way for the desires to produce or maintain free software. Those are done because the producers and maintainers experience some kind of reward from doing so.
> Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
I can't pay my rent or my server bills in "prestige". Entirely different.
I can't pay my rent or server bills in "bitcoins". I need to leverage my bitcoins in some way to get "dollars" that I can then pay my bills with. Non-monetary payment is still payment. Rare pokémon cards are payment too.
Also, in fact, people get things that otherwise cost money all the time based on prestige.
You absolutely can, because you can sell the bitcoins and turn them directly into money in your savings account. There are exchanges that declare their exact value. You can't do that with prestige. There's no exchange and no market.
Crucially, money, bitcoin, and pokemon cards are all transferrable. You can't transfer prestige to someone else, so it has no value in financial transactions.
Transference doesn't matter, because exchange is not a requirement for gain. People get things merely from having prestige/influence/power all the time. It's sometimes called an award, and sometimes called tribute, and sometimes called currying favor.
> you can sell the bitcoins
Prestige is influence, and you can absolutely sell the use or effects of influence.
> There are exchanges that declare their exact value.
Payment does not need to have exact value, just non-zero expected value, which prestige definitely has. There is no exact value to startup equity either, but it's still rightly considered to be compensation for investment of labor and money.
You're thinking of exposure, not influence. And the payment is what an individual agrees to. If you don't agree to doing work to gain influence, that's up to you, just like I don't agree to doing work for bitcoins or Pokémon cards.
