> offers an alternative that... solves absolutely none of these problems.
Here is how 1sub solves or remedies the problems with the mentioned methods:
- Pay to download or for other services: With 1sub it will be more worth it because you don't just get access to that software or that service, you get access to the software and services of all developers who participate in this system.
- Accepting donations: While 1sub keeps some of the voluntary aspect of donations, you also get something for your money.
> folks can still pirate it
Yes, the point of this is not to make it impossible to do anything without a subscription. It just makes the difference in convenience between subscribing and not subscribing bigger since there are more things that you get or don't get depending on whether you subscribe.
> this effort sounds like some naive newbie took 5 seconds to think about
Interestingly I have thought about this for many years and no idea I have had before or any solution I have seen has felt as good as this one because they always fail in that the user doesn't have enough reason to pay. The main objective of this solution is to give the user more reason to pay.
> By "people" are you excluding organizations such as governments, corporations etc?
If you mean "people" as in "A world where people pay for software", then no.
I think companies, especially software companies, would like to subscribe in this system if it gets big because if they have dependencies that require subscriptions, they probably don't want anything to get in the way for their employees.
> If I'm a developer and get to chose what to charge, that means I can ask people for $0.01, and they would get access to everything from all developers of this "platform"?
You can do that but you will not make a lot of money that way. The number of subscriptions you can sell is limited so if you sell all of them for $0.01 you will probably wish you had asked for more and when you have sold out, only the more expensive subscriptions sold by other developers remain and they will make more money than you.
> The example on [0] where a developer pays credits when they get a subscriber is confusing. Should Devs "top up" somehow?
I don't know exactly what you mean by "top up" but the credits are turned into subscriptions when sold. This is how we make sure the developers can't sell infinite subscriptions. The plan is then that with time, the developers will get more credits so that they can sell more subscriptions. How fast they will get more could depend on the current value of their account, where the value could be calculated from the credits and the number of subscribers they have.
> How fast they will get more could depend on the current value of their account, where the value could be calculated from the credits and the number of subscribers they have.
So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Suppose someone develops an app which takes hardly any effort to make -- it's a hundred lines of code -- but it does something common that everybody needs so if available for $0.01 it would have a hundred million users. Which would gross a million dollars and more than pay for the development of the simple app, so the developer is satisfied with that. But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
Now let's go toward the other end of the spectrum. Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers. Those customers would pay $100 each for it, if they had to, but not if they can buy into the system somewhere else for $10 (or $0.01) instead.
In general, who is going to buy a fungible subscription for significantly more than it's available somewhere else? How do you handle the fact that the development cost of a thing isn't proportional to the number of people who use it?
> So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Everyone can get more credits. The idea is that when we think we need more subscriptions to sell, every developer would get a number of additional credits that is proportional to the number of credits they have (with active subscriptions converted to credits for the calculation).
> But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
That would be very difficult for them to do since the number of subscirptions they can sell is limited by how many credits they have.
> Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers.
If you make software for only a few people and you need a lot of money then I don't think this system is for you. It is mostly for developers who make software for everybody.
> Everyone can get more credits. The idea is that when we think we need more subscriptions to sell, every developer would get a number of additional credits that is proportional to the number of credits they have (with active subscriptions converted to credits for the calculation).
This is what I mean by implicitly setting the price. You set it indirectly by rate limiting the number of subscriptions.
A service with high cost and low volume gets priced out, even if it's only somewhat above average, because people can buy a subscription from someone else for less.
Conversely, if subscriptions are rate limited then no one has any incentive to sell them for less than the market rate, which is in turn set by supply and demand (and you having your hand on the supply knob). Why would anyone charge less, or pay more, than the median price?
Then anyone who needs more than that is priced out, and if you allocate credits based on how many people sign up or use a service, the service that provides only trivial value but to a large number of people gets a ton of credits disproportional to the value of their service.
> where someone pays a single subscription and gets access to all content providers on the platform (in this case content is software), where creators get a proportion of the subscription fee
It is like that, except that users buy the subscriptions directly from the developers. 1Sub doesn't handle any money. This also means that the developers get 100% of the money (except for any transaction fees depending on payment method).
I know that is a possible problem. Partially, that problem exists with everything; advertisements make people buy from the most popular brands even if they are not the best. Other than that, the developers in this cooperation have to trust each other so if someone is just popular and doesn't make any good software, they would not be accepted by the other developers to join.
> What if the person does make decent software, but is a huge influencer?
Then they would probably be able to make more money selling subscriptions than other developers that are less known.
I don't know how different that would be though from if they sold physical products.
One important thing here is that there is a limit to how many subscriptions one developer can sell.
This is done to emulate physical products as much as possible.
Also, they would probably sell the subscriptions for a higher price than other developers, since they can, which would mean that people who don't know about that person would buy from someone who is cheaper.
> Why not opt for the Spotify model? Usage = money. Why turn this into a popularity contest?
That means there has to be usage statistics collection in all software.
Since the software has to be open source, that could be abused a lot, including removed.
I also don't like the idea of having any requirement like that on the software.
It would for example require that the software has access to the internet which doesn't work well for some software.
> I don't know how different that would be though from if they sold physical products
I mean that's the literal point of this website, no? In the real world, a sale is a sale. Imagine going into BestBuy, leaving $100 at the front, telling the clerk to put it all into Sony (because Sony is 4 cool kidz) and then just grabbing a nVidia graphics card and Apple AirPods.
> One important thing here is that there is a limit to how many subscriptions one developer can sell.
Definitely interested in seeing how this will play out. Sounds like a recipe for either (a) a super cool, tightly nit community with high quality contributers who care about their software or (b) a dump for software which woudlnt cut it in the real world market.
>Also, they would probably sell the subscriptions for a higher price than other developers, since they can, which would mean that people who don't know about that person would buy from someone who is cheaper.
My game theory senses are tingling. Why would I incentivize people into buying other people's subscription while gaining access to my stuff?
>That means there has to be usage statistics collection in all software.
You could always implement it on your end, right? Could be download based, or whatever. A one time thingy.
> I mean that's the literal point of this website, no? In the real world, a sale is a sale. Imagine going into BestBuy, leaving $100 at the front, telling the clerk to put it all into Sony (because Sony is 4 cool kidz) and then just grabbing a nVidia graphics card and Apple AirPods.
Ok, I see what you mean now. I think the distribution of who gets the money in 1Sub would be similar to donations, with two remedies:
- The owner of the paywall that made you subscribe gets a 10 credits bonus as described in [0]. This will lead to more money to the people who make the things that you actually try to use.
- If someone is popular, they will either run out of subscriptions to sell, or they will sell them at a higher price. In either case that makes it possible for the less known developers to sell more subscriptions.
What you get access to is everything that is protected using this site. Anyone can create paywalls. Here is an example of a link that only lets subscribers view this comments page:
The difference this is supposed to make is that currently most people don't pay for free software. I don't for example. That is because I don't need to. This system is supposed to make more people pay, which should mean that all developers get more money. Giving access to someone who subscribes to someone else is part of what makes this work and if the developers can accept that, they should all benefit from it.
But I don't get any $ from it unless they sign up on MY site, right? Since there's no sharing mechanism.
So I don't see how joining in would benefit me - if anything I'd lose a bit of revenue from people who would have paid and now find they don't need to because they're signed up for some other product which I have no hand in and no revenue from?
> But I don't get any $ from it unless they sign up on MY site, right? Since there's no sharing mechanism.
Exactly.
> So I don't see how joining in would benefit me - if anything I'd lose a bit of revenue from people who would have paid and now find they don't need to because they're signed up for some other product which I have no hand in and no revenue from?
It would not benefit you if the average person paid for multiple free software projects. In that case, they would only have to pay for one instead of multiple.
I don't think that's the case though, so this solution should make more people pay for free software and that should benefit the developers on average.
The thing is that this solution scales better. If you had to pay all developers individually, that would not be worth it but with my solution, you have to pay only one.
Also, it doesn't have to be a subscription. The payment is 100% up to the developers that you pay, so they could sell a one time payment and register a lifetime subscription in this system for that.
One such service that distributes payments could sell subscriptions in this system. That's one of the ideas I have had all the time with this project but I guess I forgot to write down; payment distributers should be one of those you can subscribe to.
The whole website is very confusing. Why would a user want to subscribe to only one developer? Why does subscribing to one developer give access to all developers? Why not put yourself in the middle and offer a subscription to "1Sub.dev" and give users the same benefits?
What does it mean to "give access to downloads and other resources"? What kind of downloads and resources?
Can you give some examples of services that exist that you think don't work well enough?
> Why would a user want to subscribe to only one developer?
Subscribing to one is easier than subscribing to many. There is less friction and the user gets more for that subscription.
> Why does subscribing to one developer give access to all developers?
All developers (and everyone else) can add subscription checks to whatever they like that will let only subscribers pass.
> Why not put yourself in the middle and offer a subscription to "1Sub.dev" and give users the same benefits?
Then they would all have to pay me. I don't want that. Someone could have something against paying me. Maybe the payment methods I offer doesn't work for someone. Distributing payments seems like the only right thing to do.
> What does it mean to "give access to downloads and other resources"? What kind of downloads and resources?
It could be anything. Here is an example of a paywall for this comments page that will only let subscribers follow the link:
I'm very confused about how the distributed payment system would work. How much would a subscription cost for a user and how much would a developer see of that?
> I don't know what kind of services you mean.
You write on your website: "Why this is better than the alternatives"
If you could give examples of the alternatives that you think don't work then it might be helpful to see how your service differs from those.
> I'm very confused about how the distributed payment system would work. How much would a subscription cost for a user and how much would a developer see of
that?
Developers could sell subscriptions for any price they want. They have a limited number of subscriptions they can sell so there is a supply/demand that influences the price. Users buy directly from the developers so they would get 100% of the money (minus possible transaction fees depending on payment method).
> If you could give examples of the alternatives that you think don't work then it might be helpful to see how your service differs from those.
The alternatives are mainly the ones listed on the page above: buying things from developers in the usual way and donating. There are also other systems that work in a more centralized way where you pay the system that then distributes the money to the creators and this system differs from all of those in that it doesn't handle any money.
If you want an example, there is liberapay.com that seems to be donations with centralized payments. My system tries to be better than that because:
- Payments are less voluntary because you get access to stuff when you pay.
- Payments are decentralized so there can be more freedom of choice in how you pay.
- What do you expect open source developers to charge at minimum for access to the catalog in order to make this make sense to do at all?
If people subscribe once and access everything, it seems like they'd need to charge a lot to make it a worthwhile co-op to participate in. It feels like the amount they would have to charge would become pretty financially restrictive to access the code and not in the interests of someone who wanted to open source in the first place...
- How does this handle the scenario of a developer disappearing?
Does everyone who had access through that developer continue to have access?
It seems since payment processing is handled by individual developers, no longer would people have to pay for access to the whole catalog. Does this now mean over the long term you are handling an ever increase supply of people with access who do not pay but can transfer their access to others for free?
- How does this handle the scenario of developers with subscribers who are supposed to pay a reoccurring payment but have stopped?
Does the developer have the ability to remove access to the catalog from specific subscribers?
If the developers have the ability to remove subscribers at will, doesn't this disincentivize paying at all because paying gives you no security in your access you just bought? What is your plan to arbitrate this without access to primary payment information to confirm who is right?
- It seems like although decentralized, this approximates to the journal model but for code? Is this your intention?
> - What do you expect open source developers to charge at minimum for access to the catalog in order to make this make sense to do at all?
> If people subscribe once and access everything, it seems like they'd need to charge a lot to make it a worthwhile co-op to participate in.
I have thought about this a bit and yes, when this thing grows, the subscriptions will be worth more and more.
I haven't really done any calculations though because it's really hard to know what things will be like.
Anyway, let's try one:
Let's say there are 100 developers (individuals) and a developer wants $4000 per month. Then if we want a subscription to be $5 per month or maybe we could allow it to be $10, the number of subscribers per developer would have to be 100 * 4000 / 10 / 100 or just 4000/10 = 400. So I guess as long as the number of subscribers are a few hundreds times more than the number of developers (individuals), it could work.
> - How does this handle the scenario of a developer disappearing?
Interesting question; I have not thought about that. Developers register and unregister the subscriptions so hopefully they would unregister their subscriptions before they disappear.
If they don't do that, it could be forced by the system but there would have to be rules about that then so everybody knows what will happen.
> Does the developer have the ability to remove access to the catalog from specific subscribers?
Yes, they can register and unregister subscriptions as much as they want.
> If the developers have the ability to remove subscribers at will, doesn't this disincentivize paying at all because paying gives you no security in your access you just bought? What is your plan to arbitrate this without access to primary payment information to confirm who is right?
That is between the buyer and the seller. If you buy something and you don't get what you bought, you would try to solve that with the seller.
Of cource people can complain to 1Sub too and then maybe the other developers will lose trust in that developer and they can be kicked out.
> - It seems like although decentralized, this approximates to the journal model but for code? Is this your intention?
I have not thought much about the journal model but I can see how this is similar.
My main vision has been tax that everyone who wants to be a citizen pays so that they then can enjoy things that are not sold directly to people.
I feel like the overall system should be clearer. For instance it's not clear how the developers get credits or whether developer accounts are somehow authenticated as representing a genuine entity.
In the opening statement of the site the idea of merely trusting the user without copy protection is completely ignored, but without more details it's not clear if the proposed system is any better.
> As a developer you sell subscriptions independently; you set the price, handle the money and do all of the interactions with the customer. Then you register the subscription in the system by using a simple API.
What prevents me, as a rogue actor, from just adding all my mates to the database without them paying me anything? Would they get access to all other software from the developers who take part in this affair?
> What prevents me, as a rogue actor, from just adding all my mates to the database without them paying me anything? Would they get access to all other software from the developers who take part in this affair?
If you are not a trusted developer in the system then the API key prevents you.
If you are a trusted developer, then you can give away as many subscriptions for free as you like but you only have a limited number of subscriptions to sell so you will not make as much money that way.
> Why would developers use this over just asking for money?
More people should want to pay if they use this system because if you just ask for money, you either don't give anything in return (donations) or you give access to your stuff, but with this system, the user gets access to everything that uses this system.
> What are you going to do about people asking for 1 cent to join the network?
Developers can sell subscriptions for 1 cent but since they have a limited number of subscriptions to sell, they will not make a lot of money that way.
If you mean 1 cent to join as a developer, that is free; it's about trust. This should be a cooperation between developers who trust each other.
It means that there is a supply/demand that influences what price the subscriptions can be sold for.
Developers have a limited number of "credits" that can be turned into subscriptions.
They can get more credits by making people subscribe through their links.
There is also a plan that the credits will be multiplied and grow with time in order to keep the prices on a sane level.
> So someone can subscribe to a 0.99/month product and use several 19.99/month products?
Yes, a developer can sell the subscriptions for very cheap but then they will probably quickly run out of subscriptions (there is a limited number) and then wish they had sold them for more.
Also, the subscription is not really tied to any product; think of it more as a subscription to free software in general, that can be sold by different resellers (the developers).
Here is how 1sub solves or remedies the problems with the mentioned methods:
- Pay to download or for other services: With 1sub it will be more worth it because you don't just get access to that software or that service, you get access to the software and services of all developers who participate in this system.
- Accepting donations: While 1sub keeps some of the voluntary aspect of donations, you also get something for your money.
> folks can still pirate it
Yes, the point of this is not to make it impossible to do anything without a subscription. It just makes the difference in convenience between subscribing and not subscribing bigger since there are more things that you get or don't get depending on whether you subscribe.
> this effort sounds like some naive newbie took 5 seconds to think about
Interestingly I have thought about this for many years and no idea I have had before or any solution I have seen has felt as good as this one because they always fail in that the user doesn't have enough reason to pay. The main objective of this solution is to give the user more reason to pay.