That’s correct. But just to be clear, you don’t “swap out” blockchain for non-blockchain. Turbosrc is not a blockchain. So someone would have to fork Turbosrc and make VotePower a crypto token, and some other things. It’s perfectly useful as is and without Web3 capabilities. The point of Turbosrc is to allow voting by ‘stakeholders’ on pull requests - how VotePower is recorded (database or blockchain) is a means, not an end.
I’m not sure that I understand the problem that you’re trying to solve. If I am the user of a F/OSS project, I either buy an SLA with the maintainer, employ them to consult, or accept that anything that I want is best-effort with no obligation. As a maintainer, I will prioritise things that I think are interesting or where someone is paying me to do the work. Adding a layer of indirection to that doesn’t seem to address any of the problems that I actually have.
The thing that I really want is a micropayment and escrow system, so if ten thousand people all want to pledge 10¢ for a particular issue to be fixed, the person who raises a PR that fixes the issue can get $1,000.
For example in nixpkgs we have a lot of contributors that help with code review. From an external member sending their first PR, it’s not always obvious which review they should consider the most. They don’t know who is influential in the project. Some point system like that might help make it more clear.
Actually, nixpkgs is one of the archetypes of the many use cases that we studied. Sorta shocked you picked up on that so quick.
Smaller projects, however, will also find Turbosrc useful because, all things equal, a potential contributor will prefer to get something rather than nothing. VotePower is more than just something. Imagine two identical forks with the same level of community, for argument sake. But only one offers VotePower - they’ll grow community faster and deeper.
It’s probably just a coincidence. I have spent quite a bit of time contributing to nixpkgs and trying to better identify the various pains I encountered or saw in the process.
The thing that I really want is a micropayment and escrow system, so if ten thousand people all want to pledge 10¢ for a particular issue to be fixed, the person who raises a PR that fixes the issue can get $1,000.
There have been multiple attempts at this, like bountysource. I wonder why they never really took off, perhaps because it wasn’t integrated enough with forges like Github?
I’ve not seen one that made it trivial for me to contribute a token amount. There are a very small number of bugs (mostly feature requests) that I’d be happy to throw a few hundred dollars at. There are a few that I’d throw a couple of dollars at. There are a lot that I’d happily throw a few cents at, but which probably also affect thousands of other people who might be willing to pitch in a similar tiny token amount and have it add up to enough to motivate someone to do the work. All of the ones that I’ve seen have been very high friction. I’d like something where I could just click something in a GitHub issue to pledge the amount, have a single credit card transaction each month to collect all of the payments, and then have the money verifiably available for someone who wants to start working on the issue.
It’s because the decision-making process inside companies is incompatible with it.
A top-level executive relies on connections with people to make spending decisions. They don’t have the time to go on some platform or algorithm. Even if they delegate the fund lower, they need somebody they can blame if it doesn’t work out as expected.
Even bug bounties are hard to sell to companies. If it doesn’t directly impact their bottom line, they have difficulty convincing themselves that security matters. And they are probably right, given the small amount of blowback they get when that happens.
Since the main driver is money, you need to demonstrate that they will spend X and get back Y, where Y > X. The easiest is if the problem you’re solving is directly impacting a sale. Further, it becomes fuzzy. Then very low on the line, you have the discretionary and feel-good budgets that exist but will always be pretty small.
Actually, think your idea about micropayment and escrow system is cool. Why couldn’t VotePower holders escrow VotePower to fix PRs, too?
And what about getting more people motivated to work on your projects by offering VotePower? When choosing between two identical projects (e.g. a fork) with the same communities, for argument sake, I’d choose the one that gave me VotePower for contributing than the other one without. Something is better than nothing. It’s an edge.
Turbosrc for bigger projects with a lot contributors makes it possible to do all sorts of things not imagined yet, per blog post. Smaller projects can get momentum by incentivizing contributions to get to critical mass like that and enjoy ‘social-driven automation’. Of course, some projects are extremely specialized or don’t benefit from large communities.
About SLAs. We can all agree I’m sure that the driver of FOSS is that it’s free to users. SLAs are exceptions if someone is demanding some customization not useful to others, needs increased guarantees, or they want to sue somebody if things go wrong. Grant you that. However, most companies will do SLAs for only very limited things. There is a huge gap as most users are there because it’s reliable and free software. Most prefer to just have a feature added with a pull request if possible than some customization on the side if possible. That way you’re not managing conflicting versions as upstream advances. Turbosrc drives pull requests.
Why couldn’t VotePower holders escrow VotePower to fix PRs, too?
You could but now you’re now building a parallel currency with all of the problems that this entails. Worse, you’re actually building an ecosystem of parallel currencies, one per project. This leads to someone building derivatives markets (is 1 VotePower on the Linux kernel more valuable than one in Chrome? If I can assign them to third parties then I can trade one for the other, and now you have exchanges and so on). At this point, why not use actual currency? The system that I want would use a temporary token only for aggregation: when I offer five cents to a project, I don’t want to have to spend five cents to buy some of that project’s scrip because the transaction fees would be too high, I want to have a central entity aggregate all of these amounts and process a single credit card transaction for me at the end of the month and make the money available in large chunks to the recipients. I want currency to be fungible.
Any time you have an idea that involves reinventing corporate scrip, it’s a good idea to talk to an economist.
I know exactly what you mean. We totally understand. VotePower isn’t a crypto token. So that solves all that right there. It’s not a currency. If it’s not Web3, there is no exchanges or anything for any crypto or cash. They’ll just be super-useful points, like Github Stars, Stack Overflow or Lobste.rs points, but with way more power to them - VotePower on pull requests.
For a future Web3 fork of Turbosrc, we already understand capabilities there and the economics better than anyone. Because we had to look at it and know else has. Not because we’re the smartest or anything. However, we’ll learn more, and others, on a Web3 alpha. There is a clear path.
Turbosrc isn’t blockchain so I don’t want to confuse people who don’t care about Web3 (most of lobsters) by getting into blockchain stuff here.
This is alpha launch. So we can’t wait to see the examples. At the moment, can only speak about ourselves.
Reibase, the original creator, is dogfooding Turbosrc. Everyone involved is incentized by owning VotePower on projects we launch. So yes, it has helped us at Reibase. We have two full-time developers, including myself, and many others that helped in less than full-time ways to get where we are, without salary. That’s basically 99% of open source, free work, but few have full-time ‘free workers’ and others for months to get off the ground. And we started to go through the VC funding process.They see value in VotePower. Sponsors, backers, or contributors will be motivated by getting VotePower on your projects if they’re good. Giving people anything is incalculably more motivating than nothing.
Does this system still allow for community projects? It seems like it is built on the idea that source code is always owned by people, which is largely bogus.
I think I understand what you mean. Like there is a fear that only people with VotePower count and anyone outside is not welcome? If so that’s not what Turbosrc is.
In the status quo without Turbosrc, a maintainer is said to “own” a project. In fact you can “transfer ownership” of a repo on Github. We know that doesn’t mean the maintainer actually “owns it” if it’s under an open source license.
Turbosrc can democratize maintainership, so it’s more community than before.
Anyone who doesn’t have VotePower can still make pull requests. Instead of just a maintainer merging or not, a community merited by VotePower does it. Today, most people who make pull requests can’t merge code, so they’re not losing anything with Turborsrc. Now, those people could get a piece of the control to merge also. It only adds a layer of benefits. Democratizing.
No they didn’t. It was a 3 paragraph meta-complaint with no vision or even real content.
Still smells like a token scam, only this time they’re selling shovels.
I kept thinking this too but they make it clear that you can “swap it out” for something else.
That’s correct. But just to be clear, you don’t “swap out” blockchain for non-blockchain. Turbosrc is not a blockchain. So someone would have to fork Turbosrc and make VotePower a crypto token, and some other things. It’s perfectly useful as is and without Web3 capabilities. The point of Turbosrc is to allow voting by ‘stakeholders’ on pull requests - how VotePower is recorded (database or blockchain) is a means, not an end.
It reads like the idea is to sell you on web3 votepower, web3 being an ethereum or whatever token. I guess it lets you buy and sell repository access?
I’m the author of the post, if anyone has questions.
I’m not sure that I understand the problem that you’re trying to solve. If I am the user of a F/OSS project, I either buy an SLA with the maintainer, employ them to consult, or accept that anything that I want is best-effort with no obligation. As a maintainer, I will prioritise things that I think are interesting or where someone is paying me to do the work. Adding a layer of indirection to that doesn’t seem to address any of the problems that I actually have.
The thing that I really want is a micropayment and escrow system, so if ten thousand people all want to pledge 10¢ for a particular issue to be fixed, the person who raises a PR that fixes the issue can get $1,000.
I think turbosrc is meant for bigger projects.
For example in nixpkgs we have a lot of contributors that help with code review. From an external member sending their first PR, it’s not always obvious which review they should consider the most. They don’t know who is influential in the project. Some point system like that might help make it more clear.
Actually, nixpkgs is one of the archetypes of the many use cases that we studied. Sorta shocked you picked up on that so quick.
Smaller projects, however, will also find Turbosrc useful because, all things equal, a potential contributor will prefer to get something rather than nothing. VotePower is more than just something. Imagine two identical forks with the same level of community, for argument sake. But only one offers VotePower - they’ll grow community faster and deeper.
It’s probably just a coincidence. I have spent quite a bit of time contributing to nixpkgs and trying to better identify the various pains I encountered or saw in the process.
There have been multiple attempts at this, like bountysource. I wonder why they never really took off, perhaps because it wasn’t integrated enough with forges like Github?
I’ve not seen one that made it trivial for me to contribute a token amount. There are a very small number of bugs (mostly feature requests) that I’d be happy to throw a few hundred dollars at. There are a few that I’d throw a couple of dollars at. There are a lot that I’d happily throw a few cents at, but which probably also affect thousands of other people who might be willing to pitch in a similar tiny token amount and have it add up to enough to motivate someone to do the work. All of the ones that I’ve seen have been very high friction. I’d like something where I could just click something in a GitHub issue to pledge the amount, have a single credit card transaction each month to collect all of the payments, and then have the money verifiably available for someone who wants to start working on the issue.
It’s because the decision-making process inside companies is incompatible with it.
A top-level executive relies on connections with people to make spending decisions. They don’t have the time to go on some platform or algorithm. Even if they delegate the fund lower, they need somebody they can blame if it doesn’t work out as expected.
The process doesn’t seem very different from regular bug bounties though, and a lot of companies participate in that.
Even bug bounties are hard to sell to companies. If it doesn’t directly impact their bottom line, they have difficulty convincing themselves that security matters. And they are probably right, given the small amount of blowback they get when that happens.
Since the main driver is money, you need to demonstrate that they will spend X and get back Y, where Y > X. The easiest is if the problem you’re solving is directly impacting a sale. Further, it becomes fuzzy. Then very low on the line, you have the discretionary and feel-good budgets that exist but will always be pretty small.
Actually, think your idea about micropayment and escrow system is cool. Why couldn’t VotePower holders escrow VotePower to fix PRs, too?
And what about getting more people motivated to work on your projects by offering VotePower? When choosing between two identical projects (e.g. a fork) with the same communities, for argument sake, I’d choose the one that gave me VotePower for contributing than the other one without. Something is better than nothing. It’s an edge.
Turbosrc for bigger projects with a lot contributors makes it possible to do all sorts of things not imagined yet, per blog post. Smaller projects can get momentum by incentivizing contributions to get to critical mass like that and enjoy ‘social-driven automation’. Of course, some projects are extremely specialized or don’t benefit from large communities.
About SLAs. We can all agree I’m sure that the driver of FOSS is that it’s free to users. SLAs are exceptions if someone is demanding some customization not useful to others, needs increased guarantees, or they want to sue somebody if things go wrong. Grant you that. However, most companies will do SLAs for only very limited things. There is a huge gap as most users are there because it’s reliable and free software. Most prefer to just have a feature added with a pull request if possible than some customization on the side if possible. That way you’re not managing conflicting versions as upstream advances. Turbosrc drives pull requests.
You could but now you’re now building a parallel currency with all of the problems that this entails. Worse, you’re actually building an ecosystem of parallel currencies, one per project. This leads to someone building derivatives markets (is 1 VotePower on the Linux kernel more valuable than one in Chrome? If I can assign them to third parties then I can trade one for the other, and now you have exchanges and so on). At this point, why not use actual currency? The system that I want would use a temporary token only for aggregation: when I offer five cents to a project, I don’t want to have to spend five cents to buy some of that project’s scrip because the transaction fees would be too high, I want to have a central entity aggregate all of these amounts and process a single credit card transaction for me at the end of the month and make the money available in large chunks to the recipients. I want currency to be fungible.
Any time you have an idea that involves reinventing corporate scrip, it’s a good idea to talk to an economist.
I know exactly what you mean. We totally understand. VotePower isn’t a crypto token. So that solves all that right there. It’s not a currency. If it’s not Web3, there is no exchanges or anything for any crypto or cash. They’ll just be super-useful points, like Github Stars, Stack Overflow or Lobste.rs points, but with way more power to them - VotePower on pull requests.
For a future Web3 fork of Turbosrc, we already understand capabilities there and the economics better than anyone. Because we had to look at it and know else has. Not because we’re the smartest or anything. However, we’ll learn more, and others, on a Web3 alpha. There is a clear path.
Turbosrc isn’t blockchain so I don’t want to confuse people who don’t care about Web3 (most of lobsters) by getting into blockchain stuff here.
Has there been an open source project helped by Turbosrc? How did that work?
This is alpha launch. So we can’t wait to see the examples. At the moment, can only speak about ourselves.
Reibase, the original creator, is dogfooding Turbosrc. Everyone involved is incentized by owning VotePower on projects we launch. So yes, it has helped us at Reibase. We have two full-time developers, including myself, and many others that helped in less than full-time ways to get where we are, without salary. That’s basically 99% of open source, free work, but few have full-time ‘free workers’ and others for months to get off the ground. And we started to go through the VC funding process.They see value in VotePower. Sponsors, backers, or contributors will be motivated by getting VotePower on your projects if they’re good. Giving people anything is incalculably more motivating than nothing.
Does this system still allow for community projects? It seems like it is built on the idea that source code is always owned by people, which is largely bogus.
I think I understand what you mean. Like there is a fear that only people with VotePower count and anyone outside is not welcome? If so that’s not what Turbosrc is.
In the status quo without Turbosrc, a maintainer is said to “own” a project. In fact you can “transfer ownership” of a repo on Github. We know that doesn’t mean the maintainer actually “owns it” if it’s under an open source license.
Turbosrc can democratize maintainership, so it’s more community than before.
Anyone who doesn’t have VotePower can still make pull requests. Instead of just a maintainer merging or not, a community merited by VotePower does it. Today, most people who make pull requests can’t merge code, so they’re not losing anything with Turborsrc. Now, those people could get a piece of the control to merge also. It only adds a layer of benefits. Democratizing.