Developers Should Have Less Power.

In a recent Reddit comment, a user named freework wrote Dogecoin should strive to be developerless. You might be surprised to hear how much I agree.

I disagree that Dogecoin needs fewer developers, but I agree that developers should have less power. What does that mean?

Let’s talk about power.

Energy Converted Per Unit Time

Sorry, physicists. The here is the ability to influence others. If we all agree to one extent or another that decentralization is a fundamental and foundational goal of Dogecoin (along with fun, memes, satire, and not taking ourselves too seriously), then we must relentlessly examine centralization and find ways to minimize it where possible.

What does “influence” mean and what does “centralization” mean? We have to examine these concepts too.

Let’s start with “centralization”.

In the Interest of Workers

The simplest and purest centralized system makes decisions in one place. One entity makes those decisions and everyone else involved has to live with those decisions. If you’re a small holder and the central authority decides you have to sell or give your koinu to a large holder, you’re going to have to sell or give away your koinu.

That’s an extreme example.

Other examples might be “Transaction fees can never be less than 1 Doge” or “Block difficulty must always be at least 6”.

Dogecoin’s decentralization means it’s good that, for example, block difficulty adjusts frequently as needed, or, with the release of Dogecoin Core 1.14.5, transaction and fee limits have been reduced. While these are defaults, you can configure these to other values if you want. Raise or lower them as you wish. Developers don’t mind.

Developers don’t, but the network might, and that’s the right entity that should mind.

In a centralized system, your own choice might be as simple as whether to participate. In a very centralized system, you might not even have that choice. Your choice matters more in a decentralized system.

The Famous Waggle Dance

Of course, you’re only one part of an entire network. Suppose I want to buy some apples to make cider, and I am willing to pay no more than $24 USD per bushel. I’m sure I can find an apple seller somewhere at that price.

If I raised my bid to $30 per bushel, I could get just about any popular apple variety anywhere.

If I lowered my bid to $10 per bushel, I might be able to get some Red Delicious apples. Yay, I guess.

There’s no central apple pricing authority. There’s just a bunch of folks interested in buying and selling who may or may not be able to find each other and agree.

The closer my own preferences are to the common agreement of the network as a whole, the more likely my transaction will clear more quickly.

By reducing the default recommended transaction fees, the developers influenced transaction costs, but by making transaction fees configurable per node, shibes who run nodes control how the network as a whole behaves.

As a developer, I don’t have the time or energy to run hundreds or thousands of nodes myself to influence the network. I can participate with the nodes I do run by setting the fees I’m willing to accept. (Spoiler alert: I use the defaults.)

If the community of shibes running nodes decides that higher fees are better than lower fees, then fees will gradually rise. That doesn’t mean you won’t find nodes willing to validate transactions at lower fees. It means you’ll have to work harder to find them.

More importantly, it means the opinions of developers about fees matter only insofar as we run nodes ourselves.

Reflections on Trusting Trust

What if the system didn’t work that way though? What if the person with the biggest wallet or the person who ran the most nodes (not 51% of nodes, but the person with the plurality of nodes) had the biggest voice?

What if running a node were so expensive or troublesome or time consuming that only the biggest players could do it? Nation-states, exchanges, venture capital firms, private equity companies. Suddenly that odroid or a Raspberry Pi running off solar power and a USB drive doesn’t get much of a say anymore.

In this case, I think developers need to have a say, as long as that say is “the community is open to all good actors, large and small, who are willing to help the network, not hurt it”.

This is why there’s no single one official wallet. The Core wallet is (in my opinion, not speaking for all other developers, contributors, or users) the reference wallet that represents the protocol and ensures a stable and consistent network experience.

There can be other wallets.

There’s no single official tipping mechanism or payment processor or blockchain browser. There should be several.

There’s no single recommended hardware configuration for running a node, not for storage space or network capacity or number of nodes serviced. (There are recommendations, because you should have at least 5 or 10 GB of storage space and expect to spend a few hundred megabytes of bandwidth, but that’s about setting your expectations, not about rejecting potential nodes.)

This doesn’t mean that Dogecoin Core lacks opinions about how to use a node or a wallet. Far from it! Even though there’s a lot of code and opinions and user experience inherited from Bitcoin, Luckycoin, Litecoin, etc, there’s no reason Dogecoin Core can’t be friendlier, easier to use, more helpful, and more enjoyable.

With libdogecoin, there can be dozens of clients, focused on all sorts of circumstances and conditions: lightweight wallets, mobile devices, embedded device transaction watchers, simplified and novice-friendly clients, clients in web browsers, etc.

I’m excited to see the work Michi and KBluezr have done to relay transactions over radio links, for example. You don’t need an always-on network connection to use the network!

Technically you don’t need libdogecoin to do any of these things either, if the network and protocol and features are all documented well. Yet a reference client (Core) and a reusable second implementation (libdogecoin) already mean that both implementations can keep each other honest, because they have to work together or we all lose.

Rules are Meant to be Written

I had an interesting conversation a while back online, where someone said “Wait, you’re a developer? That’s so cool! I didn’t realize you were here among us mortals.”

Humility is important! I often remind myself of the old Peter Parker quote: socks first, then shoes. No matter how often I think translating ideas into working code is a superpower (and it kind of is, the same way convincing a community to do something cool is a superpower, or writing a good guide is a superpower, or organizing an event is a superpower, or helping make sure that things happen on time is a superpower, or lobbying powerful business interests to do the right thing is a superpower), it’s also good to remember that developers without users are just playing with code.

If the developers do something stupid, node-running shibes have every right to say “Let’s not update” or “Wow, I’m glad that feature is optional” or “Maybe we should fork the code”. The goal isn’t to make everyone vote on every idea and completely decentralize development, though.

As I see it, our goal is to develop a network that’s resilient to attacks, scalable between big players and individuals, open to further invention and utility, and trustworthy.

This means promoting decentralization and individual power over centralization.

This means giving nodes the power to decide specific details.

This means including diverse voices in discussions and implementations (this is yet another reason I like to see translation contributions; the more diverse countries and languages and backgrounds our contributor base encompasses, the more ideas we can have for how to build utility)!

If anything, the most important power and influence developers can wield is shepherding this responsibility wisely. Do the decisions we make and the features we implement (or don’t implement) retain power for shibes or make it more likely for whales to run away with things? Do they make it easier to build new and interesting things, or do they make a boring “people buy it only to hold it because they want the price to go up” thing more common?

Is our work making the world better? Are our users enjoying themselves more? Are they frustrated less?

I think a lot of those rules are unwritten rules of free and open source software, and where they’re not rules at all, written or otherwise, they should be. I think that’s doubly important where we’re trying to build something that has advantages over centralized, secretive, high-barrier-to-entry financial systems.

If 1 Doge = 1 Doge, then surely 1 Shibe = 1 Shibe, regardless of who that shibe is: developer, user, dabbler, potential user, whale, whomever.

It’s up to the entire community to emphasize that, and it’s up to developers to write the rules in code that enforce that. That may be the last power we can ever consider giving up.