I feel like the only protection against AI in general, not just for tickets, is trust.
If I trust you, you can do whatever you want as long as I trust you.
If I don't trust you, you can do whatever you want; I will just block or ignore everything you do.
It's when we try to interact with random people that we get problems.
Doing that will become less and less possible the more AI grows.
We will have a future where trust is very important.
I just publicly released the first version of my
web+email+database combined server package that
I have been using myself for a while now for all
the different server based projects I have been
working on.
I try to keep it as small and simple as possible
while still being flexible and containing everything
in one package that you need to write server applications.
It also has no dependencies except for very common
stuff like a standard C library and a Unix-like
operating system.
> 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.
It's when we try to interact with random people that we get problems. Doing that will become less and less possible the more AI grows. We will have a future where trust is very important.