“Working in the open” gets used the way “synergy” gets used. People nod. Nobody asks what it means in practice.

Here’s what it means in practice.

The default is visible

Working in the open means your process is visible by default, not just your outputs. The code, the decisions, the tradeoffs, the dead ends — all of it is accessible to anyone who wants to look.

For a software project, that usually looks like:

Code in a public repository
Issues and tasks tracked where contributors and users can follow along
Decisions documented in writing, not buried in meeting notes
Changes reviewed publicly before they’re merged

For a non-software project — a service redesign, a policy proposal, a community plan — the same principle applies. Share the work as it develops. Not just the polished version.

What it is not

Open does not mean unstructured. Open does not mean anyone can change anything. Open does not mean you accept every pull request or every suggestion.

A well-run open project has clear ownership, clear standards, and clear processes for contribution. The openness is about visibility and accountability, not about giving up control.

This is where most organizations misunderstand it. They hear “open” and think “chaotic.” The best open projects are actually more disciplined than closed ones, because the discipline has to be legible to outsiders, not just understood by insiders.

Why it gets resisted

Two fears come up consistently.

Fear of being judged on unfinished work. This is the big one. People worry that sharing drafts or in-progress code will make the organization look incompetent.

In my experience, the opposite happens. Showing your process signals that you’re thinking things through. Hiding your process signals that you might be hiding problems.

Fear of losing competitive advantage. This is more common in the private sector, but it shows up in government too — agencies protecting “their” data or tools from other agencies.

For most organizations, the work itself is not the moat. The execution is. Sharing your approach doesn’t diminish your value. It demonstrates it.

The economics

Open process has real costs. It requires more discipline — you can’t leave credentials in a config file or write commit messages that say “fixed stuff.” Documentation has to be good enough for someone outside your team to follow.

It’s slower at first. Writing decisions down takes more time than talking about them in a hallway.

But it pays back in ways that compound.

Distribution costs drop. When your code or your data is public, people find it on their own. You don’t need a sales team to get a tool into someone’s hands. Government agencies share links to open repositories the way they’d share a memo. The work spreads through the networks that already exist.

Switching costs drop — and that’s a good thing. If your users can see the code and run it themselves, they’re not locked in. That sounds like a disadvantage until you realize what it signals: you have to keep earning the relationship. Organizations that depend on lock-in to retain clients are telling you something about the quality of their ongoing work.

Surface area for improvement increases. Every public commit is an invitation for someone to find a bug, suggest a better approach, or build something adjacent. Most people won’t. But the ones who do are exactly the kind of collaborators you want.

And the basics compound too. Every time someone new joins the project and doesn’t need a three-hour onboarding call. Every time a client asks how you do something and you can point to the work itself. Every time you need to understand why a decision was made eight months ago and the answer is already written down.

The compounding benefit of institutional memory captured in public is hard to overstate.

What this looks like for us

Civic Studio keeps project code in public repositories. This website’s source code is on GitHub. Touchpoints, Jurisdictional, and Eligibility Rules are all open source — the code, the data, and the process.

This isn’t altruism. It’s a business decision.

Public code gets better scrutiny. Open data gets reused and improved by people we’ll never meet. Transparent process attracts collaborators who value the same things.

And when someone evaluates whether to work with us, the portfolio isn’t a slide deck. It’s the work itself.

Starting

You don’t need to open everything at once.

Publish your roadmap. Put a design system in a public repo. Write about a decision you made and why.

The point isn’t to perform transparency. It’s to build the habit of working in a way that creates accountability and institutional memory as a byproduct.

That’s what working in the open actually means.

What Working in the Open Actually Means