The case for open infrastructure
blog.mediocregopher.comWhat 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 owners. Create a public independent board to oversee it. Put any profit back into the service. The architecture will not matter.
> 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.
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.
This is a cool idea. Any successful examples of this happening that you can think of? I vaguely remember some co-op uber alternatives but haven't heard of them taking off without regulatory intervention (banning uber).
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).
Note that Gitea will start adding federation support to their code forge, and at least 3 other projects are dedicated to code forge federation at: https://forum.forgefriends.org
Also a self-hosted alternative to KeyBase is at: https://keyoxide.org (minus the chat parts).
> The source code for Keybase is, right now, fully open source on their Github
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.
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.
Just give me a dockercompose.yml. That’s all I need.
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 hope supabase will follow this at some point.
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!
Stripe bans plenty of startups.
no new company should take its own payments?
No new company that isn’t a payments company should take its own payments, IMO.
It is probably a waste of time and resources to file for a banking licence in multiple jurisdictions, become part of the global payment system, seed deposits with central banks and establish swap credit lines globally - all to facilitate the $2.99 no ads plan on their iPhone app.
Do you really want to deal with the legal and compliance hurdles of handling credit cards/debit cards/etc. right out of the gate? (Assuming that isn't what your new company is about).
No, I do not.
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.
Unless your business deals exclusively in cash and/or cryptocurrency, I don't think you can really avoid that. Even if you are dealing with a credit card company directly, that company could ban you out of the blue for suspician/politics/obscure-AI-decision.
Using Stripe etc. adds another point of failure.
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.
Every hole in the wall restaurant and convenience store somehow manages to do it... are they so much better at all that??
I think they usually use some sort of point of sale device and service to handle credit cards. That is pretty analogous to using a payment processing service.
That is a payment processing service.
They pay a bank for merchant services. They don't become their own payment services.
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).
I think there are a few common themes, from my perspective:
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.
Super thoughtful, thanks. Notably these are all social or legal rather than technical in nature and that does seem to be a viable way to tackle this. There are a number of ventures that have stayed relatively consistent over time (like hundreds of years) by staying small and focused [0]. I hope that postgres and linux will be on that list in 1000 years.
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.
If avoiding sale-of-ownership to a capitalistic entity is a strategic goal, incorporating as a non-profit is one tactic. Among other protections, ownership of non-profits in the US (501c3) cannot be purchased by for-profit entities.
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...)
If DLTs push forward, maybe traditional centralized services will have to keep up.
Smartphones are like thin clients. If you already subscribe to bandwidth, why not compute too?
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 realistically becoming compute platforms?
> 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.
You are correct for the use case you specified, but his isn't about utilizing the entire grid at once. A common use case would be getting for example Minecraft chunk generation offloaded, or rendering VR content at a very local compute node.
Yeah, it's a good term to use when testing the waters for blockchain acceptance. =)
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.
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.
This is what i've seen from the "decentralized aws" cropping up: cryptocurrency is used to incentivize people to provide compute to the network, not for people to try to do the actual computing tasks they want on the cryptocurrency layer. So the long term with that is the centralized computing providers will have to provide better/cheaper services as this space grows and becomes more competitive (alot of this overlaps with some of "orcale" networks/protocols).
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.
I think you'll find that most people here have a tech background and that 'Infrastructure' is the stuff that code/apps/platforms run on. It's the physical stuff that resides these days in cloud providers.
Nothing to do with Marx or any philosophy.
> most people here
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.