Working in Public

Three Things #182: August 10, 2025

Working in public is almost always a good idea, but it will almost never feel comfortable. My advice? Do it anyway, and do it now rather than later. You might be pleasantly surprised by the experience.

Note: the title of this issue was inspired by the excellent book of the same name by Nadia Asparouhova, which I highly recommend.

Early in my career I spent six years working on proprietary software in traditional finance. At the end of those six years, I had literally nothing to show the world for the work I had done. I had no ownership of and no license over my own work: no proof of work, so to speak. No portfolio to share with the world.

Then I discovered open source and I haven’t looked back. Today I run mostly open source software, and I work on mostly open source software. It allows me to sleep well at night: I know that, even if a project I work on fails or isn’t completed, the work product still exists in the public domain. I can still tinker on it, share it, and, at the very least, point to it and say, “I made that.”

I recognize how fortunate I am to be able to support myself and my family through open source work, which historically has had sustainability issues, but I’m also heartened by the fact that open source is eating up more and more of the software stack. The rise of open source software and commons-based peer production, including many crypto ecosystems, means that more and more people are able to support themselves in this fashion.

Since moving to open source, I’ve leaned into the open source ethos in areas of my work that don’t involve writing or running code. For instance, I strong prefer to use text editing, document management, and CMS tools that work with straightforward markdown files rather than a proprietary format (I use an open-source app called Logseq for all personal note taking and have become a huge fan). I use Github issues and project boards as a project management tool. Openness is something I’ve been thinking strongly about, and advocating for, since my early days working on Ethereum.

In fact, even though we’re not writing much code right now, I think of House of Stake as an open source project. Like open source, it should be permissionless to contribute: find an open issue on Github, jump in and start creating value. The “core team” should emerge organically over time through this process of meritocracy and permissionless value creation.

One baby step we can take today towards this vision is ensuring that the core team works in the open as much as possible. I try to dogfood this in my own work: making working documents public by default, communicating on public forums by default, etc. But something I’ve noticed, in this project and in others I’ve contributed to, is that most people just aren’t comfortable working in this fashion, in the open. Most people, even those with whom I feel strongly values aligned, actually have a pretty strong aversion to this style of work.

This topic came up a few times recently in the context of House of Stake, so I thought I’d put down my thoughts here: why working in the open is so critical, what valid concerns other people have, and what to do about them.

Thing #1: Why It Matters 🚨

Open source software has shown us beyond a shadow of a doubt that working in the open is good for several big reasons. These ideas were revolutionary when open source was new, but today they’re no longer controversial.

The first and most obvious is increased transparency and trust. It’s much easier to trust a process when you can see how the sausage is being made: who’s doing what, when, and for what reason. It’s a form of proof of work, and it’s related to the idea of trustlessness (or trust minimization) that’s so popular in the crypto industry: you don’t need to trust what I tell you because you can verify it for yourself. All of my work is out there, in the open, at all times. It stands on its own merit, and doesn’t need to filter through multiple layers of management and marketing before it reaches the market.

This leads to a unique form of meritocracy that’s only possible in open source, which I consider to be one of the most meritocratic institutions in the world. In this way, it’s thoroughly American. In nearly every open source project I’ve seen, the project leader (benevolent dictator) is widely respected on merit, and not just because they were appointed or anointed. One of the key mechanisms that protects this meritocracy is the fork: if participants disagree with the leadership they’re free to peacefully fork, appoint a new leader, and go elsewhere.

A related idea is platform risk and agency. One of the main reasons I’m not interested in running or contributing to closed source software is because the maintainer could disappear at any moment and take the entire project with them. You have to blindly, naively trust that this won’t happen. Working in the open is insurance against this happening. In the worst case, if the maintainer disappears or turns evil, you can always fork the code and appoint a new maintainer.

Another way of putting it is that, in closed source software, unless I work for the company that maintains the software, I have zero agency over the software: how it’s designed and written, how it’s operated, etc. Open source is the antidote, and goes a long way towards addressing the principal-agent problem, since the agent can become the principal, peacefully and permissionlessly. I find that a lot of otherwise very smart, motivated founders simply don’t understand this dynamic and the game theory at work here, and as a result, they struggle to attract talent who prefers to work on open source and have greater agency.

Then there’s the fact that working in the open leads to better outcomes. The best example of this is probably security: in general, opening up your code to “many eyeballs” belonging to a global community of developers means that bugs and other issues will surface more quickly. By contrast, proprietary software tends to rely on “security through obscurity.” I think the same thing can be true of non-technical work: when I work in the open, whether it’s drafting documents, doing project management, or just sharing ideas, community members can (and often do!) weigh in and share ideas that I hadn’t thought of, point out holes in my logic, etc. (For more on the idea that open, community-driven software can be superior to the alternative, see Worse is Better and The Cathedral and the Bazaar.)

Finally, I think working in the open also just inspires us to do better work in the first place. I probably do spend just a little more time reviewing my open source code for bugs, adding useful comments and commit messages, etc. And, when working in public, I tend to think twice before I hit commit, something I don’t do when working on closed code that I know almost no one will ever see. The same is probably true of other open work. I’m going to put a little bit more effort into it, to make it just a little bit more polished, before sharing it.

In this industry we talk a great deal about values like permissionlessness and decentralization, which we generally discuss in the context of things like financial inclusion. But it’s important that we dogfood our values and put them to use in our everyday work. Conway’s law says that we’re destined to architect systems in ways that reflect our own communication structures. If we want to build software that’s open and decentralized, it’s absolutely essential that we first work in ways that are open and decentralized.

Thing #2: Dirty Laundry 🧺

I’ve been encouraging my teammates to share their work publicly for many years. The most common form of pushback I get is, “Sure, I’ll do it when I’m ready.” This mindset is wrong, but before I try to tear it down, let me steel man it.

If you ask people why, they often can’t clearly articulate a reason it’s too early to share something. It just feels too early. This is a classic sign of an ingrained behavior—something we do without thinking. It’s something that most of us were taught from a young age, and most professional settings also drive this point home. When we’re given a task, we go off and perform the task, on our own or in a small team, and then share it only once it’s done. That’s just the way work is done. Isn’t that how it’s meant to be done?

If pushed, in response I typically hear something like, “Well, it reflects poorly on the brand. People will think my/our work is sloppy. We’re professionals, and we should act like professionals and share our work once it’s polished.”

There are a few good excuses for not sharing work that’s still in progress—more on this in a moment—but this is not a good reason. Because by embracing working in the open, we’re explicitly telling the world, “You’re going to see how the sausage is made. It’s supposed to be messy.” No one can hold that messiness against you if you’re upfront about this point.

What it really boils down to is a feeling of vulnerability. Working in the open feels a little bit like being naked in public. There isn’t actually anything wrong with it: it’s the default state of things and it’s not going to hurt you or anyone else. If you work up the courage to try it, it’ll make you grow a little bit. There’s no good reason not to do it, other than a little fear, a little nagging voice in the back of your head, but people are still afraid of doing it. They don’t like feeling vulnerable.

But the benefits, as outlined above, are myriad. Vulnerability, it turns out, is one of the best ways to build trust. People will trust you more, and perceive your work with greater legitimacy. Your work product will be better.

Another issue with working behind closed doors is that, despite your best intentions, the work will never actually be fully ready to be shared. This is the reason that the “as soon as it’s ready” mindset is the wrong mindset. In my experience, in 99% of cases, the right moment to open source something is the moment of inception—with vanishingly few exceptions. You’ll always find something else to improve, another excuse to postpone opening your document, chat group, or codebase. And the longer you wait, the harder it gets: the more lines of code there are to review and “fix” before sharing.

As I said, there aren’t many reasons not to work in the open, but there are a few that are worth mentioning here. The first and most obvious is legal constraints. There are certain scenarios where you simply don’t have control over the IP, or where the IP is so sensitive that it cannot be shared. (In reality, the types of companies who keep all of their IP proprietary are probably also not the kind of places you want to work, but that’s a topic for another day.)

Another reason is privacy. I’m a privacy maximalist, and privacy matters a lot. I’m also an openness maximalist, but these two values aren’t at odds. After all, what privacy really means is selective disclosure: we can choose to be very open about certain things, and keep other things completely private. And, of course, we need consent for sharing anything that’s remotely personal or sensitive about another person. For instance, I don’t feel that salary information needs to be made public, to say nothing of something like a performance review, but these are sensitive personal topics. If someone wants to share their own information, more power to them! But it’s not appropriate for me to share this information about my team on their behalf.

Another, extremely common form of pushback I get from people who aren’t used to working in public is that community members will openly criticize their work. And, sure, there’s some truth to it: every community has those one or two toxic members who will examine every open doc, nitpick, and extract the most embarrassing, damaging part of the document to air your dirty laundry to the entire community.

In my experience, however, the sort of community member who does this, no matter how misguided, also tends to be the sort of person who highly values transparency. When they perceive that transparency is lacking, they’ll lash out at whatever scraps of information are available—and often invent conspiracy theories to fill out the rest. By resisting such people, by choosing to work in private, you’re only making the problem worse. They’ll lash out even harder. And, if you’re able to embrace working in public, you’re actually giving them what they want, which in my experience can appease them and defuse the situation. Show them that you have nothing to hide, and remind them that your work is still a work in progress!

But how to make the transition to working in public?

Thing #3: A Modest Proposal 🧸

I have a modest proposal that’s extremely simple and straightforward: work in the open by default.

Rather than thinking of working in public as a major behavior change, rather than thinking of it as a burden—that every time you create something new you need to consider whether and when to share it—my strong advice is to just adopt a new default. Everything, everywhere, always should be public unless you have a strong reason not to open it up. It’s as simple as that.

Defaults are very important thing! Even when we have the option to deviate from them, we seldom do. Most of our everyday workflow tools are designed for working in private: email, instant messages and chats, documents, etc. This makes sense, because there’s some danger in making things open by default if the user doesn’t fully understand the consequences. Some applications make it possible to share things globally, but they make it difficult—Trello boards come to mind, for instance.

But there is an exception. Thanks to the open source software movement, we have very powerful tools like git and Github that make it easy to work in the open. The technical details and nuance of how git works are beyond the scope of this issue, but git was designed specifically for projects with many contributors, all around the world, working on the same codebase simultaneously. These many contributors review each other’s work and assemble it back together into a final, upgraded project: in git terms, this is called a “merge.”

My modest proposal is that we apply the same logic to non-software work, and adopt the conventions—and, to some extent, the tools—of open source for non-software work. I’ve done this quite successfully over the years in several projects including Ethereum, Spacemesh and now NEAR and House of Stake.

No, this approach isn’t appropriate for every project. But try it and you might be surprised how many situations it actually suits, and for how many different kinds of projects. The beauty of git is that you get transparency and merge-ability out of the box: when tools like Github are used correctly, everyone can see what everyone else is doing at every point in time. You no longer need to make transparency explicit through the use of things like standups or status updates. The code repository itself is the status update. When someone asks, “What are you doing?” or “What did you do last week?” or “What’s this person’s role?” your answer should always be the same: point them at the commit log filtered on the git handle of the user in question.

I’ve found this git-centric workflow to work surprisingly well for general project management, for ecosystem governance, etc. In governance as in open source, transparency and accountability are key. Github issues and kanban boards generalize quite well as general project management tools, and Github’s project management features have gotten more powerful over time. And it doesn’t have to cost any money: in Github, open source organizations and repositories are free. (You only have to pay if you want to work in private.)

In addition to unlocking all of the benefits of openness described above—greater trust, better outcomes, etc.—you get the added benefit that, like in an open source project, everyone can see at every moment what needs to be done. It’s the best way to invite an entire community or ecosystem to contribute to something. There’s no need to ask what needs to be done. Check the “project management” repository, look for issues tagged “Help wanted”, and jump in, permissionlessly—just as in open source.

Of course there’s a great deal more you can do for transparency. Rather than just opening up the meta-work—the task issues, kanban, etc.—you can open up the documents themselves. You can make your meetings public, or participatory, or even move to public chat channels. There are tradeoffs to each of these decisions. But in my experience taking this first step of opening up even just high level project management is a huge step in the direction of greater transparency, accountability, and trust.

As with anything worth doing, like starting a family or a company, there’s never a right moment or a time when you’ll feel totally ready to start working in public, so my advice is to take the plunge and enjoy the ride. You won’t regret it.