Comments URL: https://news.ycombinator.com/item?id=47796935

Points: 2

# Comments: 1

Wow, look at the page source! It's an insane amount of javascript. I wonder what it does.

If I have an original idea and ask you to do the work, should I get copyright?

Points: 6

# Comments: 7

This is the kind of project that creates something from as little as possible, where the only things you need to get started are a very basic RISC-V assembler and a computer or emulator to run it on.

I don't have anything interesting to show yet because I just started yesterday, but one day I will show you.

It makes sense, doesn't it, that those who run arbitrary code on your computer every day, are people you feel like you can talk to? So let's talk to them. Make friends. Know each other. Help each other.

And if you feel like they would not care about you because so many people are using their programs, switch to a program that fewer people use, made by someone who can care about you as a human, someone who would be happy to have you as a user.

If you feel like there are too many developers, so that you can't talk to all of them, switch to simpler programs made by fewer people.

Comments URL: https://news.ycombinator.com/item?id=44150262

Points: 4

# Comments: 1

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.

https://www.robalni.org/server/

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.

1. What things do you avoid using or doing?

2. What are the reasons that you don't want to do or use this thing?

3. What do you do or use instead to solve the same problem?

Comments URL: https://news.ycombinator.com/item?id=37226131

Points: 5

# Comments: 3

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.

> 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.

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.

[0] https://1sub.dev/about/how-it-works

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.

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.

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.

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.

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).

You can read about it here (bottom): https://1sub.dev/about/how-it-works

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.

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.

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.