I don’t see that continuing over time. There is no way that donations alone can sustain major servers as they see growth over time. You’re also going to get to a point where a server’s admin switches from being a hobby to a job.
There aren’t that many websites that can run on donations alone.
Well the decentralized nature of the Fediverse helps spread out the cost. For example you can rent a VPS (virtual private server) for like ten or twenty dollars a month and throw a Lemmy instance on it. That’s where many Lemmy instances are currently living. There’s your own time involved in maintaining the instance, but the cost should remain pretty stable.
Conversely, a centralized service where all users have to be supported by an individual or company owned cluster of machines can get very expensive. I can’t imagine the operating costs for a site like YouTube with the demand for data storage and bandwidth.
Well I think it depends on the balance of growth between nodes and users. If growth of users and growth of instances is proportional, it should be sustainable.
That leaves the question of how well Fediverse software can deal with increasing node numbers. I hope that engineering question has been properly considered. It’s like the available number of IP addresses when they initially designed TCP/IP, they never considered four octets might not be enough for future growth.
Nothing on the Internet seems to indicate that use distribution will be even. Power law is going to get involved and some nodes are going to get massive.
Well yeah that will happen. Initially I looked for instances with the biggest subscription base. Then after some reading about the Fediverse I realized that kind of thinking does not apply. You get everything regardless of which node you’re on (barring any defederation). Maybe most will realize that, but you’re probably right most will not. We’ll see how it goes.
I don’t see that continuing over time. There is no way that donations alone can sustain major servers as they see growth over time. You’re also going to get to a point where a server’s admin switches from being a hobby to a job.
There aren’t that many websites that can run on donations alone.
Unless you have a huge red banner across the top of your screen like Wikipedia lol
Well the decentralized nature of the Fediverse helps spread out the cost. For example you can rent a VPS (virtual private server) for like ten or twenty dollars a month and throw a Lemmy instance on it. That’s where many Lemmy instances are currently living. There’s your own time involved in maintaining the instance, but the cost should remain pretty stable.
Conversely, a centralized service where all users have to be supported by an individual or company owned cluster of machines can get very expensive. I can’t imagine the operating costs for a site like YouTube with the demand for data storage and bandwidth.
The cost gets spread out, but not completely. You are also going to run into problems if an instance takes off.
The costs are manageable now, but is that sustainable?
Well I think it depends on the balance of growth between nodes and users. If growth of users and growth of instances is proportional, it should be sustainable.
That leaves the question of how well Fediverse software can deal with increasing node numbers. I hope that engineering question has been properly considered. It’s like the available number of IP addresses when they initially designed TCP/IP, they never considered four octets might not be enough for future growth.
Nothing on the Internet seems to indicate that use distribution will be even. Power law is going to get involved and some nodes are going to get massive.
Well yeah that will happen. Initially I looked for instances with the biggest subscription base. Then after some reading about the Fediverse I realized that kind of thinking does not apply. You get everything regardless of which node you’re on (barring any defederation). Maybe most will realize that, but you’re probably right most will not. We’ll see how it goes.
The hosting costs isn’t on the user end, but the instance end.