11–20 of 35 posts
I get the spirit of this article. But one of the key things to consider is the operational overhead of maintaining infra for auxiliary services far outweighs the value it provides. There are a few things like payments, notification, monitoring(logs/metrics etc) startups shouldn't build from scratch/self host anymore, unless they plan to take on the incumbents in those fields.
What the author essentially is asking for are public services. They just want a term to justify not having to think about the million other problems with running such a service. The typical "I'm a computer person, I can solve any problem with just code" thing. If you want "open" public services, form a co-op or nonprofit to develop the service. Make all users 'members' who fund it. Make both the workers and users the…
Edit: I would think the problems would be around consensus (getting people moving in the same direction) and lack of incentive (getting people moving at all).
I get the spirit of this article. But one of the key things to consider is the operational overhead of maintaining infra for auxiliary services far outweighs the value it provides. There are a few things like payments, notification, monitoring(logs/metrics etc) startups shouldn't build from scratch/self host anymore, unless they plan to take on the incumbents in those fields.
Earlier quoted context omitted.
DLT = Distributed Ledger Technology? If so, I’m curious — how does the amount of compute on these distributed networks compare to the cloud platforms, and what is the overhead resulting from the infrastructure protocol? I’ve heard numbers to the effect of the global BTC network having a throughput of a couple of dozen transactions per second, for all the song and dance. Is there any hope of such networks realisticall…
I think the general idea is to sell normal compute (think lamba or workers) via some coin or something. As the computational power on chain is very slow and expensive.
I get the spirit of this article. But one of the key things to consider is the operational overhead of maintaining infra for auxiliary services far outweighs the value it provides. There are a few things like payments, notification, monitoring(logs/metrics etc) startups shouldn't build from scratch/self host anymore, unless they plan to take on the incumbents in those fields.
no new company should take its own payments?
What the author essentially is asking for are public services. They just want a term to justify not having to think about the million other problems with running such a service. The typical "I'm a computer person, I can solve any problem with just code" thing. If you want "open" public services, form a co-op or nonprofit to develop the service. Make all users 'members' who fund it. Make both the workers and users the…
I feel this is somewhat harsh reading.
From TFA:
"Even if someone were to figure it out, the system is probably designed to be a globally scalable service, not a small clone being hosted for the benefit of a few."
I'm in the same camp as the author -- I appreciate the current public service, but don't expect someone else to do everything for me here if/when this service seizes up. I'd appreciate being able to replicate the features of the extant globally-scaleable existing system into something that would keep my needs serviced.
Cost-wise, the author does not seem to be demanding something for nothing, or on-going actions from someone else.
At what point did ICT (horizontal services) become "infrastructure"? I use quotes, because at this point it is really superstructure in the sense of Marx. I think we should be very careful about casually using that word.
Nothing to do with Marx or any philosophy.
I get the spirit of this article. But one of the key things to consider is the operational overhead of maintaining infra for auxiliary services far outweighs the value it provides. There are a few things like payments, notification, monitoring(logs/metrics etc) startups shouldn't build from scratch/self host anymore, unless they plan to take on the incumbents in those fields.
A positive example for this is mailcow [1]: all you need to do is pulling the repo, editing the mailcow.conf and running “docker compose up”. Logging is preconfigured, and the watchdog just works.
It’s dead simple and provides secure defaults. It’s ready for production in very little time. That’s what I would love to see from more projects.
I hope supabase will follow this at some point. I really like the idea of a self hosted firebase. But right now there is too much to take care of for a single person to actually take a self hosted supabase into prod (be it for side projects or whatever).
I like the spirit here. Any frameworks people like for building stuff with distributed or federated architecture? Thinking about this in relation to how one could build long-lived web services (like bandcamp [0]) that aren't owned by a single entity (or can't be sold at least). [0]: https://news.ycombinator.com/item?id=30665311
1. Be popular "for the people": as in, you're used by and contributed to by a passionate community. (Wikipedia, vim/emacs, pretty much any gnu project) Commercial interest is tangential or very indirectly related to the service.
2. Alternatively to (1), be a valuable and costly-to-replicate component of many large, for-profit companies doing their normal business (linux, postgres/mysql, wordpress, almost any apache/cloud native project, nginx)
3. Especially if you're going for (2) over (1), adopt a governance strategy that prevents a project's popularity from bending to commercial interests (postgres, linux for positive examples; see mozilla and countless recent "oss" companies for counter-examples of varying degree).
4. Keep your footprint small, and do not raise outside capital, even if you're going route (2). This one speaks for itself; you don't want outside influence to force a sale or watering down of (3). It is perfectly OK to earn revenue (for donations, support, etc.), but be extremely wary of debt or equity sales.
There are tactics for achieving these ingredients, such as registering as a non-profit, developing a project in public with a FOSS license, using federated architecture.
IMO, there is no correct choice to make amongst those tactics: it really depends on what you're building, and for whom.
In general, I'd be suspicious of projects that are allergic to revenue, but want to be long-lived. Be suspicious of projects that religiously insist on some tactic (e.g. fediverse) without a sound justification rooted in strategy.
Really? My understanding was that the client and some libraries they use are open source, but the actual server code is closed source. Although if Zoom isn't going to continue maintaining keybase, then open sourcing the server code seems like "the right thing to do" (at least morally, and probably from a PR standpoint as well). Even if they did want to continue maintaining it, it would be a good thing in my opinion, but moreso if the project will die otherwise.