The Plan

Hello! Welcome to Project 2027!

This might seem like an odd introduction. Usually, when you visit a movement's website, you'd expect to find a landing page with a slick design, a sign-up button for a newsletter, maybe a call to action to donate. But this is not your average movement.

You see, Project 2027 is a plan.

It's a plan that doesn't need a central leader or organization, and it doesn't need donations or funding. The core of it is an idea that can spread like a seed. That anyone can take, plant, and watch grow - including you.

Not that you need to! I get it, we're all incredibly busy, and I'm betting you don't like the sound of even more work at the moment. But this plan operates on the Ratatouille model, which is to say:

Just substitute "chef" with "someone who can take this plan and run with it". So, give this plan a quick skim, and if you think it sounds like a good idea, share it, and you'll have done your part.

Now, on to business!

Ok, so what is the plan exactly?

Project 2027 is a plan to accomplish 4 core goals. In order from most immediate and realistic, to most abstract and ambitious, they are:

1. Rebuild local and state government tools and services, to save money and improve real people's lives.
2. Build state capacity and momentum, so that we're ready for the federal level in 2029.
3. Take technology and the internet back from the billionaires, and return them to the public.
4. Reshape the economic narrative for a generation.

The plan starts with government software. Right now, we effectively rent our software from private companies who charge us for every change, who lock us into their systems, and who have little competition. The US is set to spend roughly $313 billion on technology in 2026 at the federal, state, and local level, and that cost keeps going up.¹

Despite all of that spending, I'm willing to bet that you've had to deal with a government website that feels like it hasn't been updated since the 90s. Clearly, wherever all those tax dollars are going, we're not getting our money's worth.

This is an opportunity.

If we build the software ourselves, then we own it. And to put it in perspective, we could hire 100,000 developers, pay them $200k each (which would be competitive with Silicon Valley),² and that would come to just $20 billion a year.

So, for the same money, we could have a massive public workforce maintaining our software, have plenty left in the budget to cover cloud hosting costs and other expenses, and send the rest of it back to the people and toward other services.

That sounds great, but... how?

We use the same process that built the Internet: open source!

You've probably heard about or used some open source software (OSS) over the years. But Silicon Valley's dirty little secret is that open source runs the world.

Let's give a quick example of what I mean with Windows vs Linux.

Microsoft's total revenue for Server Products was $98.4 billion in 2025.³ Windows Server, their direct competitor to Linux, is some portion of that, but it also includes income from their cloud hosting suite and databases. Overall, that's a bit over a third of their total revenue.

If Open Source Corp was a company, and it charged the same amount as Windows to license Linux, then it would bring in $1.3 trillion a year, give or take a few billion (my own estimate, napkin math here).

In fact, if we compare this theoretical revenue number to each of the Mag 7 companies, we can see that it beats all of them.⁴

And if that's not enough, here are some other products and systems that only exist because of open source software:

• Android Phones (Linux)⁵
• iPhones (Darwin, which used much of FreeBSD)⁶
• Playstations (FreeBSD)⁷
• Smart TVs (Android and Linux)⁸
• Teslas (Linux)⁹
• Car dashboards from Toyota, GM, Ford, Honda, Volvo and more (Linux and Android)¹⁰
• Starlink Satellites (Linux)¹¹
• Every top-500 supercomputer (Linux)¹²
• Much of the smart-home and embedded world¹³

Now, how much do you think we spend on maintaining all of that software every year? Well, it's hard to say exactly, but somewhere in the realm of $7.7 billion, give or take.¹⁴

To put this in perspective, let's compare the profit that Linux would make to the profit the Mag 7 make, combined.⁴

Linux would have nearly double their profits and a 99% margin, a level of efficiency which is unheard of. In other words, open source is possibly the most efficient bureaucracy the world has ever seen.

So, we're going to follow that process. In fact, you are following it right now. This document is effectively a Request For Comments (RFC),¹⁵ which is how we make decisions in the open source world. We put ideas out there, along with everything needed to make them come to life, and then we discuss, we coordinate, we build momentum, and we get things done.

Here's how it'll work.

Phase 1: Build

Start by finding a piece of government software that fulfills as many of these qualities as possible:

1. Relatively simple
2. Isolated from other systems
3. Low stakes
4. Expensive
5. Really bad
6. Something that multiple governments need to deploy

For example, In Virginia, the occupational licensing software is woefully out of date.¹⁶ You still have to snail mail the application for a license to Richmond, where two employees manually type the details into the system. There have been two attempts to replace it since 2018, both of which have failed and cost the state millions.¹⁷

Occupational licenses are a great starting point, because they're relatively straightforward and isolated, every state needs them.

In a different direction, we could focus on parking apps. Specifically, let's talk about ParkMobile.¹⁸ They recently have started to upsell a subscription to get rid of their fees.¹⁹

This is what writer and tech critic Cory Doctorow calls "enshittification",²⁰ where apps capture a market and then, when it's too difficult for users to switch, begin to make the experience worse and extract profit.

ParkMobile is good software, but it's trending in a bad direction. The app is very simple, it's low stakes, and every single city across America needs it, so this would be a perfect test case for Phase 2.

The larger point here is, software is literally everywhere, and we can find incremental pieces to pick off one at a time.

Once you find the software you want to replace, the next step is to work out how to do that. There are many potential paths to doing this. Multiple states (including Virginia!) have been putting together digital service teams, so there is clearly appetite to invest more in tech teams at the state level.²¹ NYC also created the Public Interest Technology (PIT) Crew under Mamdani, which is exploring improving government tech in different ways.²²

Here's where average people can lend their voices to the process. Developers will need to build these apps, but everyone can lobby their local and state politicians to use and fund them.

You can put it to them this way: This experiment would cost maybe $1-2 million over the next 2 years, at most. That may sound like a lot, but it is a rounding error in a state or large city budget.

This is a low risk, high reward play, and if anyone succeeds, we all do, thanks to Phase 2.

Phase 2: Share

Once one city or state builds the software in the open, they can then share it, and we can turn a win in 1 state into a win in all 50.

Every state will have its own requirements, processes, statutes, etc. But we should be able to make it configurable for each state's needs, as long as we plan accordingly.

Now, there is one more key aspect here. You know how apps on your phone and computer update automatically? We need to implement something like this, but for services.

One of the main reasons states and cities will buy a service rather than building it or running it themselves is the cost of maintaining it.²³ We need to bring that cost down, and there will be two main components to doing this:

1. Standardize cloud server deployments, so that you can just plug in an off the shelf machine and have your own mini cloud. Or plug a bunch into a datacenter and have a public one for your town, your city, or your state. Cloud compute should essentially be a commodity, and it shouldn't matter where you get it from.

2. Standardize server app deployments, so that managing your own instance is a cakewalk. This includes everything from rolling updates to migrations to backups and so on.

It needs to get to the point where an IT admin for a rural school can plug in a "cloud-in-a-box" server, setup School OS, check autoupdate, and generally expect things will work and be backed up properly, even if the machine gets unplugged by the janitor or coffee is spilled all over it.

The good news is that most of the work for this phase has already been done in the open source world, we just need to standardize some of the details, harden it, and make it bulletproof.

If we do this, the result will be a set of tools and software that can be easily replicated in states and cities across the nation. Tools that will be durable and independent, with the ability to fork or opt-out while still staying up to date and never falling behind.

Phase 3: Expand

Once we've done this successfully once, we'll have:

1. Established credibility and gained trust
2. Built the plumbing to be able to do this for many other applications
3. Have saved enough money to justify our own, continuing paychecks

From here, we open source the rest of the government one tool and system at a time. We start with the low hanging fruit, the easy and obvious wins. We then move onto more complex systems. We move onto the federal systems in 2029, and we move onto other systems beyond that.

Yes, beyond government. Because there are many, many systems which we all depend on and which should be open.

Consider, for instance, hospitals and medical systems.

Have you ever had trouble getting your records from one doctor to another? Have you had to fax them a form, or fill out your list of prescriptions for the umpteenth time?²⁴ Have you ever wondered what would happen if you were unconscious and taken to a hospital where they didn't happen to have your penicillin allergy on file?

And thinking more broadly, what if there's a disaster, and the internet is offline? Shouldn't you be able to run the system in isolation, indefinitely, for something so important? A triage station in a war zone, or a rural hospital in an impoverished community? Hell, if we ever get there one day, what about Mars? Are we just going to ship a copy of Epic up there along with the first crew?

The fact is that companies who run these systems don't have much incentive to make these changes. Their users are the hospitals, and the hospitals are locked in. The regulatory hurdles are large, and new players in the market can't catch up.²⁵ This is exactly the type of market failure where government is supposed to step in and push for change, and that's exactly what we'll do.

From there, we can start to build all of the tools we rely on in public, as apps that we can all run, and own, ourselves, on our own personal clouds. Your email, your calendars, your docs, owned by you, not on a corporation's servers or locked into their ecosystem.

Because software is infrastructure that doesn't decay, it doesn't get used up. You can make an infinite number of copies of it, and give them away, and it doesn't take anything from anyone.

We can all have our own internet of tools, each bubble able to talk to the others seamlessly, but ours.

No tracking software spying on our every move.

No lock-in that we can't escape.

Software for us. By us.

Phase 4: Maintain

Now, for the last and most ambitious goal: Changing the economic narrative for a generation.

Neoliberalism has dominated policy since the Reagan Revolution in the '80s, but most of the assumptions it made about markets have been in question since the 2008 financial crisis. With this last election, we have seen a thorough rejection of that old model, which gives us an opportunity to tell a new story.

I call this story Open Capital, and it works like this.

In Open Capital systems, the source code of the means of production are open: they have no IP protections and can be examined and copied by anyone. This enables permeability, which is when users can cross the divide and become maintainers of their own tools. This brings us a few powerful dynamics:

1. It allows the pain-signal to propagate. User pain is what economists call tacit knowledge: it is difficult to articulate and often only becomes clear through direct experience. This makes it very difficult to turn into a price-signal in traditional markets, but in a permeable system, the pain itself can propagate as a signal, and this guides attention and resources.

2. This propagation creates a market dynamic, without prices or currency. Users gravitate toward the biggest and most painful problems affecting themselves or their teams, and come up with fixes for them. They then share these fixes, and other users evaluate them and spread them based on what works best.

3. This market discovers and fixes the most painful problems through statistical aggregation of the pain-signal. If there are a million users for a given tool, and their is a major pain point in the tool, then statistically, it's more likely that users will discuss it, complain about it, and try to fix it. More users being affected means more attempts at fixing it, which means more likelihood it gets fixed, and more innovation while trying to fix it.

The system that emerges over time in these conditions is what the political scientist Elinor Ostrom called polycentric governance: a system where multiple centers of decision-making interact and adapt based on local knowledge and needs.²⁶

This is how open source is able to maintain the entire worldwide software ecosystem with so little funding. It's an economic paradigm that works at scale, and it's already how the world works today.

To increase permeability, we can incentivize people by providing access to education, time to work on problems, and financial and community support. We can also reverse it, and seed the population with developers, having them go out into the field and finding the pain points directly. This is the model that the U.S. Digital Service (USDS) and 18F used to great effect. They brought technologists in from industry for "tours of duty" and embedded them inside agencies, working side by side with the civil servants who actually ran each program,²⁷ and it's a proven method that gets results.

Users are the best innovators

If you need more evidence that this works, just look at Operating Systems. The very first operating system, built back in the 1950s, was created by users solving their own pain points.²⁸

In fact, users have always driven innovation. There's a whole field of research into this very topic,²⁹ and the amount of innovation that comes from solving personal pain points is absolutely massive.

None of this relies on currency. It also doesn't rely on altruism or idealism. It is still driven by people's self-interest. It just turns out that collaborating and sharing systems and ideas and standards with each other is usually in everyone's self interest, in the long run.

In this way, we can create a system that addresses and prioritizes user's pain, rather than shareholder profit. And through that, we can build a better economic system for everyone.

One final thought

Have you ever been frustrated by what I call the Ron Swanson effect, where people who don't believe government can work well get into office, and proceed to make government not work well? It's frustrating that we may get 2 or 4 or even 8 solid years to build something, only to have it be torn down just as it's beginning to show its returns on investment. A recent example being the IRS direct file program, which was piloted in 2024 and expanded in 2025, only to be shut down that same year.³⁰

Well, if we can get the system that I described above in place, then that no longer is an issue. Because unlike today, they wouldn't be able to lock us out.

At some point, these systems will become self-sustaining and ubiquitous. Trying to block upstream changes to critical services will be like trying to stop updates to Linux. People can drag their feet, but the ecosystem will move forward regardless.

Common Concerns and FAQs

Is there any precedent for this?

Yes actually! There are at least two examples that have worked quite well in the US:

1. The Evergreen library system. About 1,800 libraries run on Evergreen, an open source platform that was initially built by the Georgia state government for its statewide library network. The original developers eventually spun out to a private company that later became a non-profit, and they provide consulting services to the states that require them, but many states administer the system on their own. Georgia itself has run its network mostly in-house since 2012.³¹
2. The CompactConnect data system for sharing occupational licenses between states. This was actually put together in just the last few years. The interstate compacts for counselors, occupational therapists, and audiologists and speech-language pathologists (each one a joint agency created by its member states) built it together through the Council of State Governments, and they jointly own the code, which is open source. The first states went live on it in 2025.³² It shows that there is appetite for building this way, and that the process can work across many states working together.

And there are more internationally:

1. DHIS2, a health information system built at the University of Oslo, which more than 80 countries now use as their government-wide system of record for health data.³³
2. openDesk, an open source office suite built for public agencies by a company the German federal government owns. It's now on around 100,000 government workstations, and rather than build its own notes app, Germany develops one jointly with France.³⁴ Governments across Europe are making similar moves, including switching to LibreOffice.³⁵
3. X-Road, the open source data exchange layer behind Estonia's digital government. Estonia and Finland now develop it together through a shared institute, and Iceland, Ukraine, Québec and the German state of Schleswig-Holstein have joined as members.³⁶
4. GOV.UK Notify, the UK's open source service for sending government emails and text messages. Canada copied the code and had its own version running within days, and hundreds of Canadian government services now use it.³⁷

There are also some historical examples that haven't worked well or have been mixed. Two major ones:

• The Department of Veterans Affairs' VistA system for VA hospitals. The system was initially developed in the late 1970s, so it had a massive amount of legacy cruft, but it effectively worked as an open source platform (its code is in the public domain) that hospitals regularly modified and updated on their own, driving innovation. For a long time, it was actually well rated! As late as 2014, doctors rated it the best electronic health record in the country.³⁸

  The fragmentation is what caught up with this system in the end though. Every hospital ended up having its own custom deployment, based on legacy languages and databases and their own unique plugins or options. By 2019, the VA was running about 130 different versions of VistA.³⁹ This made it essentially impossible to migrate forward, and eventually, the VA decided to replace it with Oracle Health.

  However, that transition has not been going very well either,⁴⁰ showing the weakness of contracting out systems to spec. And in the end, this is why the work in Phase 2 is crucial. We need to make sure that even if individual users have customizations, everyone can stay up to date with the latest and not create fragmentation or decoherence.

• The American Rescue Plan, which set aside $2 billion to modernize unemployment insurance. The Department of Labor's plan for that money leaned heavily on open source, building modular tools that any state could pick up and reuse.⁴¹ There were a number of issues with this, from the number getting slashed in half during budget fights, to red tape and roadblocks being thrown up everywhere, to the funding ultimately being clawed back by the Trump administration.⁴²

  But I think the bigger issue here was that we were going after the biggest target first. The funding was focused on the unemployment insurance system. That is an absolutely massive system, serving tens of millions of Americans, and run separately by every one of the 50 states under federal rules.

As I note below in "Why start with state and local governments?", massive systems that serve that many people are a very different beast than many city or state systems. And the fact is, after the last 50 years of neoliberal dominance, do not have the muscle to build those kinds of systems yet. This is why we need to focus on smaller systems first.

This is why we need Project 2027.

We need to build up the processes, the talent, the skill, and the developer base, so that when we go to take on the leviathans that are the federal systems in 2029, we are ready.

Is it secure?

One very well established but counterintuitive thing about open source is that it ends up being more secure than closed source. Think about it this way, which would you trust more:

1. A lock with designs that are hidden, with some testing every so often by lock pickers that the company hires, OR
2. A lock with designs are publicly available, and the company hosts a yearly conference to bring all of the best lock pickers and safe crackers from all over the world to try to break it? And also, those lock pickers and safe crackers all use the lock themselves?

The second one tends to be safer!⁴³ In fact, this is how modern cryptography algorithms were developed, in public at math conferences.⁴⁴

Now, we do still need to provide funding for open source. Maintainer burnout is a huge issue, and there can be weak points in the system, as we've seen recently with several high visibility vulnerabilities.⁴⁵

I know for many that these vulnerabilities were just another sign of how bad things are, how underfunded security systems are, and so on. But, I think that hidden within that mess, there has been a demonstration of the immense efficiency that the open source process has. Time and time again, people leap into action and get critical systems updated, and the word is spread incredibly quickly. It's not universal, and it should absolutely be better funded with more preemptive measures taken. But, can you imagine if the process to fix a vulnerability like this had to go entirely through a government or corporate bureaucracy instead?

If anything, these recent issues point exactly to the solution outlined above. One of the key problems is the fact that so many apps and services are running their own artisanal mix of various systems with different, outdated versions.⁴⁶ This includes many commercial apps, because every company is ultimately trying to maximize profit, and routine maintenance and security fixes regularly get pushed aside for new features.

If we make server apps work and update as smoothly as an app on your phone, then we can get the ecosystem moving together more smoothly and ensure that critical security updates rollout quickly and effectively. The end result will be a safer, less stressful world for all of us.

What about the geopolitics of it?

This is another one that people misunderstand. Wouldn't we just be giving our software away to the world for free? Won't that mean that the US is going to be paying to maintain other countries' software while they freeload? And what about China/Russia/North Korea/Iran/<Insert-Baddie-of-the-Month-Here>??? Do we really want everyone to have access to our tech?

Again, counter-intuitively, yes, because it creates a self-balancing system of power.

You see, in the open source world, nobody owns the code, because anyone can copy it at any time. Geopolitically, this means that no one country can unilaterally turn off systems for another country, nor can they make decisions without the consent of other countries.

However, if you are the primary maintainer of an open source system, you do get much more influence. You get to set the standards for how things work, to lay out the fundamentals of the design, and to make sure that your country's interests are prioritized.

Basically, doing work buys you influence and power, without giving you full control.

Now, if you push your advantage too far, then the ability for other countries to fork and make their own copy acts as an effective check on your power. Consider the situation with Google Chrome and Microsoft Edge. In 2020, Microsoft switched Edge to use Chromium, Google's open source browser, under the hood.⁴⁷ This cemented Google's lead in browser marketshare, and Google maintains most of the control over Chromium's development to this day.⁴⁸

Yet, Google can't make decisions unilaterally. If they started to build features that benefitted themselves at the expense of Microsoft, then Microsoft would fork and begin maintaining their own version of Chromium, dividing the market and challenging Google's dominance in the space. This keeps Google from holding Microsoft over a barrel, and you can see how a similar dynamic would work between countries.

It's important to note that this is not a perfect system. For instance, Google made some user-hostile changes for ad-blockers in the recent Manifest v3 transition that really upset the community,⁴⁹ yet this was not enough for Microsoft to push back on, likely because it did not disrupt their business all too much. The same sort of issue will always pop up between companies and states sharing a commons, which is why it is important that we exercise our voice and build our capacity to advocate for ourselves, rather than ceding control to a few companies (or countries). The threat of forking must always be actionable, and occasionally taken when needed, as the community has done successfully in the past on several occasions.⁵⁰

Now, there's one last bit here, and I'm afraid it's somewhat bad news for the US tech industry: This transition is already happening.

I would say that it got locked in between the war with Iran, and separately, the US cutting off access to Anthropic's Fable model this summer.⁵¹ The war exposed many countries' dependency on oil, and began driving momentum toward energy independence and creation of closed-loop systems broadly.⁵² Nobody wants their economy to tank in a matter of weeks due to disruptions in that supply chain, especially when they can happen for such arbitrary and capricious reasons.

And right as that calculation was being made, the US revealed that it could do this for technology services overnight.

Imagine what happens if you shut down Office 365 in a nation because they aren't bending the knee? An economy comes tumbling to a halt because it can't use simple spreadsheets, documents, chat apps; tools it has come to rely on.

Nations around the world are now looking at how to move onto sovereign platforms for all of these critical functions, and the end result is more than likely going to be that they use open source platforms rather than rebuild the wheel in every nation.³⁵

So, if we don't do this, our influence is going to fall, and we're going to be at the mercy of whoever does do it first.

Like, for instance, China.

Just saying. Only a matter of time before they realize this all too, if they haven't already.

Why start with state and local governments?

A few main reasons:

1. The problems are smaller in scale. As noted above, the more people you need to serve, the harder it is to build an app that serves them all. An app that works well for 100,000 users is very different from one that works well for 1 million or 330 million.
2. The payoff is bigger. If we solve a problem at the federal level, then we've solved it for one user, at least within the US. If we solve a problem at the state level, then we've solved it for 50 users, and that means we can theoretically 50x our savings and build momentum faster. Same goes for cities and counties.
3. We get more than one shot. If we can get many state and local governments involved in this, one way or another, there's a higher likelihood that one project will succeed. One project succeeding buys every other project more time, and pays off for the cost of any other projects that do not succeed for whatever reason.

At a higher level, one generalization I repeat often is "economies are grown, not designed". You can try to throw a lot of money at a problem, but that requires central planning and can be easily mismanaged. You also end up putting all of your eggs in one basket, even if that basket attempts to diversify with many teams.

Successful open source projects emerge organically. Linux was the combined effort of many programmers over multiple decades,⁵³ putting together individual pieces until it finally was ready for prime time. Similarly, to take on the big problems, we must first take on the small ones and build up our capacity for bigger problems.

We need to build the teams and the communities in each state and city across the nation, so that everyone can be a part of the process.

What about compliance?

Anyone who starts looking into government processes and technology immediately hits a wall of complexity when they start to understand the level of compliance and safety that these tools need to fulfill. Governments often prioritize these concerns over baseline efficiency, for a variety of reasons that make sense to governments and that we will not get into here.

The point being that yes, we must meet this bar. Full stop. I reiterate this below in the contributor notes, but we will need to make sure that the systems we build can be audited and seen as compliant, and that they minimize risk for the state. We will also need to extend that to ensure that the system of continuously and automatically updated apps that this document envisions can also be compliant, whatever that entails.

The good news is that we aren't starting from scratch here. Compliance has traditionally been a point-in-time audit: a system gets reviewed, approved, and then more or less frozen, because every major change means another review. But most of those checks can be automated and run in the deployment pipeline on every single update, scanning dependencies for known vulnerabilities, verifying that configurations still match the approved security controls, recording exactly what changed and who signed off on it, and blocking the release if anything fails. The federal government is already heading this way. FedRAMP, the program that approves cloud services for federal agencies, and the Department of Defense are both building paths where systems are validated continuously instead of being reauthorized from scratch.⁵⁴

If we build those checks into the shared platform once, then every app and every state that runs on it inherits them. That's a much stronger compliance story than a binder that gets updated once a year.

This will be difficult. It is a very high bar to fulfill.

However, there are major benefits to doing it this way, specifically for us as citizens. Governments are punished far more harshly than companies for failing to meet compliance and safety standards. This is something that we have seen over and over again, and is a major driver of the privatization of our government systems and technology.

The best way to fix that, if you are a government that must deploy and manage its own code, is to build software that does not break.

Higher quality, safer, more secure. This raises the bar in every way that we actually want as citizens and constituents. So the benefit outweighs the cost.

No more passing the buck.

How does AI fit into all of this?

This plan is AI agnostic, in the sense that we could decide to use it if we determine that it helps and is worth the cost. However, I recommend reading this breakdown of the issues and limitations with AI driven software development.

The long and short of it is, we do not want:

• 1000 versions of the same tool.
• Mountains of sloppy code that is brittle and difficult to work with.
• Codebases that are so large that you must use AI to work on them.
• All-in-one tools or systems that lock people into workflows and prevent them from branching out, configuring, and combining tools to meet their own needs.

We DO want:

• Unified, configurable tools with clean APIs.
• Platforms that can integrate with many tools, rather than single-use apps (think Home Assistant rather than Philips Hue).
• Where appropriate, different parallel distributions for different use cases (see: the Linux distribution model).
• Stable tools that people can depend on.

AI is great for building a lot of mediocre things fast. It's not so great at unifying things, building coherence, and ensuring future extensibility.

This is on top of the other problems that AI presents from a sociopolitical perspective, such as the environmental impacts, the issues data centers are causing in local communities,⁵⁵ the jobs that are being automated prematurely,⁵⁶ than the overall lower quality of AI made products.

All of this given, the tentative recommendation is to not use AI or to minimize use of AI, and to build out teams of engineers instead. While it may be tempting to think of AI as a shortcut here, the fact is that slow and steady wins the race.

The industry is hemorrhaging talent right now. Engineers have been (metaphorically) slapped in the face repeatedly over the last few years. They have been told that they are redundant, that they aren't needed anymore.⁵⁷ They have told their managers that AI code is not up to par, and the managers don't care. Mandates have come down from the top,⁵⁸ and engineering has been seen as a cost sink rather than the valuable pool of labor that keeps systems alive and functioning well.

This is, once again, an opportunity.

Talented engineers with years of experience are more willing than ever to try something new. Discontent is pervasive, and if we harness this, we can take that talent and redirect it to work for the people, instead of for profit.

Isn't this just the Fediverse?

If you've been plugged into the details behind platforms like Bluesky and Mastodon, you may have heard about the Fediverse, a portmanteau of "federation" and "universe". The idea is very similar to the end state I sketch out above - people run their own nodes and services, own their own data, and no one platform, company, or individual can control a network.

The thing is, the Fediverse is basically hard mode of this direction.

Social networks have to scale to the size of the planet. The whole point is that you can connect to everyone via a shared protocol, so systems like Twitter, Whatsapp, Discord, and yes even email have to work across any number of people and scale up to 8 billion users (or beyond, if you count the bots).

Compare this to, say, an elementary school, which has maybe a few thousand concurrent users at a given time. Even city and state services only need to scale to millions of total users, and far fewer concurrent users. That may sound like a lot, but is a much, much easier problem to solve compared to the scale of social networks.

Plus, along the way, we can improve real people's lives and save public money, which we can then argue should fund more of this work.

I think the long tail of this is that we meet somewhere in the middle.

Aren't open source apps kind of janky?

One of the main arguments people will make is that while open source is great at making tools for coders, it takes the unified vision of a real company to make a quality, user friendly experience.

I disagree. The issue is (a) the lack of funding for OSS, meaning that developers only really get to focus on solving their own needs, and (b) the lack of permeability, as discussed above.

Both of these issues can be worked on across the board, and we can build tools and systems that have excellent user experience. There are plenty of examples of projects that operate this way, including:

• Firefox, which while no longer dominant, once led the pack in user experience, and has recently experienced revival with browsers like Zen building on top of its open core.⁵⁹
• Signal, the messaging app that has become more and more prolific due to its security and ease of use.⁶⁰
• Blender, a 3d modeling mainstay for decades that has gotten steadily better and better in many ways, and is the go to for small studios and people just getting started.⁶¹
• Mastodon, a social network with pretty amazing UX and one of the first apps to prove that the Fediverse (see the previous section) could actually work.

We also have a major advantage now, which is that we know what we're trying to make. The internet has slowed down significantly compared to the churn of the early days. We generally know the patterns that apps have, and it's unlikely that there will be significant changes or improvements to those any time soon.

I know, I know, I can hear a bunch of people shouting "what about AI???" at the screen. Yes, AI is new and paradigm shifting in some ways. But the fact is, even if you have an AI agent filling out forms and entering data most of the time, you will still want the ability to manually review the forms, correct? And you'll still want a basic UI that allows you to navigate your data, no?

That is the part that is unlikely to change dramatically, and it's exactly the part that we can commodify and improve in the commons today.

Is this related to usaproject2027.org?

No, that site went up in 2025 and has been fairly static. While I respect the fact that they saw the need for this early, at this point the 2027 elections have happened and I think the name could be put to better use, focusing on what we can actually do here and now.

Notes for Implementers

These are not hard and fast rules, but I think it's important to say a few things about how we should go about this if we are to be successful.

We DO NOT break userspace!

These are the immortal words of Linus Torvalds, and while Linus has historically kind of been known as, how shall I put this delicately, a bit of an asshole, the fact is that this cardinal rule is responsible for much of Linux's success over the years.

Open source projects do not have the benefit of the doubt when it comes to quality. Large corporations and closed-source projects can offer enterprise service contracts and the safety of working with one of the biggest corporations on the planet. Plus, nobody ever got fired for using Windows or Oracle.

Now that Linux is dominant, technical gravity works in its favor. It would be significantly easier for users to fork the project and correct any major issues, or just wait for the next stable version, versus switching to closed source alternatives. But during the nascent, early stages, quality is of utmost importance.

We must be diligent and vigilant. We must anticipate issues and failure modes, and we must prevent them before they occur, not after. We will often not get a second chance.

We need people's first experience with replacement tools to be, at the very least, zero regression from whatever tools they're coming from. If nothing changed at all, then we've done a good job. We've saved money, we've justified our own existence and paychecks, and we can keep building and improving incrementally.

Coordinate and coalesce early and often

If this takes off, there will be a lot of projects attempting to do this. Many of them will be duplicates of each other, and while 2 or 3 attempts at a particular system or tool may be good (since it makes it more likely that one of them will succeed), what we don't want in the end is fragmentation and a hundred versions of the same tool.

Find other projects early and often, and try to see if you can work together. It doesn't matter if they're using tools or frameworks you're not a fan of, or have made decisions that don't match your taste, UNLESS you believe there are major structural issues. And in that case, raise those issues early so they are aware! Try to work with them!

As for coordination and community building, we should invest in this early and often. The boring work of running meetings, putting together agendas, taking notes, etc. is incredibly important.

TC39, the technical committee that defines JavaScript, has plenary meetings every 2 months or so.⁶² They have extremely efficient systems for getting through the agendas, which are massive. The work of putting these multi-day meetings together, running them, and keeping them on task is a full time job.

So, prioritize those roles. Make sure someone is focused on it, and if people want to contribute but can't through code, then this is a place they can instead. We will need to do a lot of coordination and communication work to create a durable community, so it is worth it.

Understand that the bar is excruciatingly high

As mentioned above government organizations are, for a variety of reasons that could fill several books, often much more concerned with risk and compliance than with efficiency. A major part of the reason why governments choose corporate software is that much of the liability for failures gets absorbed by the corporation rather than the government, even if it results in a structurally weaker system that is more fragmented and difficult to maintain.

We will need to meet that bar with excellent engineering, and we will be fighting an uphill battle. Open source solutions will be seen as risky, right up until the moment they aren't, just like Linux was.

This will mean that some projects don't make it. We have to take this on the chin, and pivot quickly when it becomes clear. As mentioned above, every project should be working to coordinate and coalesce quickly, so we can focus on the ones that are succeeding and avoid fragmentation.

Don't boil the ocean

This is a turn of phrase that means "don't try to fix everything at once." Boiling the ocean is a task so big that, with the exception of a truly catastrophic event such as a major meteor strike, it is all but impossible.

As we noted above, if nothing changed at all, then we've done a good job. Getting the software updated to modern practices, using modern tooling, owned and deployed by the state and the public, and into the open domain and open source world generally are all major accomplishments in and of themselves.

Focus on these things first. Then focus on improvements, starting with the biggest pain points first.

One thing that I struggled with for a long time was running a mile. I had asthma as a kid, and I was never that athletic in high school, despite trying my hardest. In college, I decided to get into shape, and I ended up using the C25K program after hearing about it online.

It felt far too easy at first. 60 seconds running, 90 seconds walking? I didn't even break a sweat. But I stuck with it, and day over day it got harder, but I was ready for each new level. Each week was just a little more effort, a little more of a push, than the last week. And I could hold out just a bit longer.

Eventually, I was running 3 miles, three times a week. And ever since then, I've always been able to run at least a mile at a decent pace, no matter how long it's been since I last ran.

Start slower than you think. Build momentum. Focus on the long term. Don't do too much up front, and focus on doing the things you are doing the right way.

This is a marathon, not a sprint.

If it ain't broke, don't fix it

An extension of the statement above is, legacy pieces that are working well are likely not the first ones to tackle. If there's an Oracle or SQL Server database that could be replaced with Postgres, for instance, that might be fine to replace. It also might be a nightmare. Migrations can be messy, legacy databases can have a lot of oddities you can't see or aren't considering.

Maybe, instead, you replace the app on top first, and get everything working well. Then, when you have time and resources, you go after the legacy pieces that are separable.

Don't let the perfect be the enemy of the good. But also, don't let the "good enough" be the enemy of the great.

The first part of this statement is often said, and it is truly good wisdom that is, in effect, another way of saying "don't boil the ocean." But the second part is my addition. And it's an important one, as it ties back to decoherence.

It is a very common pattern that we start migrations without finishing them, that we create interop layers with legacy systems and then forget about them and leave them to languish, because we need to move onto the next most important task.

This is just kicking the can down the road. Eventually, all of those layers come back to bite, especially in government.

We will never create perfect software. But we must strive to all the same. And in doing that, we need to finish the things we start. Get the migrations finished, and turn off the legacy database. Get the last of the design system updated. Don't leave loose ends, and don't get distracted before you do.

Another dirty secret that Silicon Valley loves to ignore is that most of the startups out there take out a large "loan" of technical debt, only to win their races, turn into major companies, and be so filled to the brim with debt that the they can't ever really pay it down. And these are companies that started in the last decade or two, that have the advantage of using all of the best practices from the start.

And the ones that don't have those advantages? Well, as they say, Visa and banks still run on FTP. They struggle just as much with these problems of legacy debt, and I cannot tell you the number of times I have seen a quarterly roadmap stacked to the brim with new features and a tiny slice of tech debt, only to get to the end of the quarter and see that none of the features shipped, and we'd hardly made a dent in the debt.

Don't make that mistake.

You are not the main character

This is a final note targeted to the Silicon Valleyites out there, with much love.

We have been told a story about ourselves for a long time. That we are making the world better through technological progress. That we are revolutionizing and modernizing ancient and broken systems through "disruption". That we can do anything with software and a pack of redbulls.

This is not how the world works.

We are not the main characters. We build tools. People use our tools to do things in their lives, and sometimes those tools are incredibly useful and helpful and they unlock hidden potential and possibilities.

But we are only the tool makers. We are not the doctors or the nurses, we are not the farmers or the construction workers, we are not the teachers or the social workers. We are their support crew. We exist to make their lives easier and better, to make their jobs safer and less painful.

We must never forget this.

And the unfortunate truth is that we have forgotten it, frequently, and with disastrous results. From tying teacher evaluations to metrics like test scores,⁶³ to providing "free internet access" in developing countries and then keeping those users in walled gardens,⁶⁴ to pushing for programs like One Laptop Per Child with the thought that hardware would somehow provide salvation to struggling students and teachers.⁶⁵

The culmination of this behavior, in it's most disgraceful and damaging form, was DOGE. A billionaire and his entourage, convinced that they knew how to fix government, and that all they needed were the keys to the kingdom to do it.

People have every reason not to trust us, is what I'm saying.

And we must earn their trust, if we are to be successful.

We must listen to their pain, and meet their demands. When the users say "jump", we must reply, in unison and with no hesitation, "how high?".

We must work to build the best software the world has ever seen. And we must remember, through all of it: We are not the main characters.

How do I help?

There are 3 main paths at the moment for contributing: sharing it, joining the discussion, and funding. The Contribute page has the details for each.