Awareness is the start. But awareness without action is just well-informed passivity.

So what do you actually do with this?

Start small

You don't need to quit your job, join a DAO, or rebuild the internet.

Start with the next thing you build, review, or design.

Before you dive in, pause for a moment and ask:

Who gains power from this? And who loses it?

That's it. Just that question, applied consistently.

It won't always have a clean answer. But it will make things visible that were previously hidden inside technical decisions that felt purely technical.

Choose where to contribute

There's another layer beyond how you build - it's where you build.

Every hour of work strengthens something. Every project you contribute to is moving in some direction.

Some systems move toward openness, transparency, user control. Others move toward enclosure, extraction, centralization. Most sit somewhere in between, pulled in multiple directions at once.

You don't need a perfect position. But you can make a directional choice - even a gradual one.

Start paying attention to what the systems around you are actually optimizing for. Not what they say they're optimizing for. What the architecture, the incentives, and the defaults reveal.

That gap between stated values and structural reality is where the most important decisions are hiding.

Contribute to what you believe in

Open source projects. Privacy-preserving tools. Public goods infrastructure. Decentralized protocols with real Missions behind them.

These spaces need engineers. Not just idealists - engineers. People who can actually build the thing, not just believe in it.

Your skills are not neutral either. Where you point them matters.

You don't have to abandon financial stability to do this. Even partial contribution - a few hours a week, a pull request, a piece of documentation - strengthens something real.

Small, consistent direction compounds.

The honest version

None of this is easy. Working on mission-aligned projects often means less money, more uncertainty, slower feedback loops.

The systems optimized for extraction are also optimized for developer comfort and compensation. That's not an accident - it's how they retain talent.

So this isn't a call to be naive about tradeoffs. It's a call to make them consciously, with open eyes, rather than drifting into them by default.

You already have the framework. You know what to look for.

The rest is just deciding what to do with that.