The case for open infrastructure(blog.mediocregopher.com) |
The case for open infrastructure(blog.mediocregopher.com) |
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 owners. Create a public independent board to oversee it. Put any profit back into the service. The architecture will not matter.
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.
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).
Also a self-hosted alternative to KeyBase is at: https://keyoxide.org (minus the chat parts).
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.
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).
we have the docker-compose in our main repo: https://github.com/supabase/supabase/tree/master/docker
with instructions/docs here: https://supabase.com/docs/guides/hosting/docker
Hope that helps!
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).
Smartphones are like thin clients. If you already subscribe to bandwidth, why not compute too?
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 realistically becoming compute platforms?
Bluntly: no.
Open (e.g. decentralized) networks must solve a unique class of problems, like Byzantine fault tolerance, in some cases censorship resistance, etc. The solutions to those problems necessarily impose performance constraints at the system level that are effectively incompatible with any nontrivial use case.
Bitcoin is as inefficient as everyone but the cultists claim. The tech I have been looking at resides in another ecosystem with a more academic bent and a much more careful approach to engineering the global economy.
The use case isn't really for utilizing all the compute of the grid for a single task, but instead finding resources for your workload in an efficient manner. E.g. paying your neighbors to generate Minecraft chunks for you without hassle or even speaking with them.
As the computational power on chain is very slow and expensive.
I think we should be very careful about casually using that word.
Nothing to do with Marx or any philosophy.
You're right. Perhaps I am speaking to the wrong crowd.
However, you may or not be aware that, as with all things in the tech-world (and tech-business world), the way we talk leaks out into wider use and is misused.
So, yes, in the bigger world it very much does have philosophical/social implications. When clueless top-mid execs bandy about words like "infra" they are inserting values into a business without realising it, inappropriately displacing a locus of control and decision making to external forces.
That's when you suddenly find your internal strategy documents have been dropped and the company set back by weeks because Microsoft decided that for you.
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.
Still, pretty curious about if we might be able to enforce it at the infrastructure level (e.g. build something that technically cannot be co-opted) rather than trust humans not to take a liquidity event. I think part of the bandcamp outrage emerged because the epic acquisition went agains what people thought was the preceived "stay indie" company ethos. I'm definitely not one of the people mad about it (I took an exit!), but the level of outrage + looking at these blockchain incumbents (which look scammy but perhaps technically interesting) has me thinking there might be a way.
A 501c3 can be a parent company for a for-profit company (e.g. Mozilla-Co is owned by the Mozilla-Foundation), so it's still possible to operate a "normal" company within the IP-ownership structure of a a 501c3.
Edit: it's worth noting that family-owned businesses with a trust component have also done really well in the last 100 years. (see the NYT, which is governed by the Sulzberger family [126 years], and many others on this list: https://en.wikipedia.org/wiki/List_of_the_largest_family_bus...)
However, I've heard (too) many stories like "our payments/ads/infra vendor banned us out of the blue for suspicion/politics/obscure-AI-decision" to ignore this. It could be fine for a start-up that is inherently risky, intended to fail early and risks Other-People's-Money (TM), but not always.
But yes, the fact that essentially all payments are bottlenecked through two vendors with no legal supervision is quite troubling.
Maybe we should form a co-operative of payment recipients? It doesn't need to operate anything, but rather be a "suicide pact" that will extoll a high price from payment processors if they try to unfairly ban a business. Some sort of a smart contract could guarantee fair enforcement.