Four Kitchens turned 20 in 2026. This post is part of What’s Cooking, a series tracing 20 years of building the web alongside our clients, our community, and each other. Each post looks back at where we’ve been and forward at what we’re building next.
Chief Executive Officer
Colleen is responsible for driving Four Kitchens’ vision and long-term strategy.
May 7, 2026
It sounds simple. And yet, so many businesses guard their ideas and lessons learned like trade secrets, convinced that keeping knowledge close is what keeps them ahead.
That instinct is understandable. As AI accelerates access to nearly everything, that instinct is increasingly costly. The competitive advantage isn’t the knowledge itself. It’s the judgment, craft, and relationships you build by applying it.
At Four Kitchens, we built a company on the opposite premise. Sharing what we know — with clients, with the community, with each other — has never been a risk. It’s been a practice. And over 20 years, it’s shaped nearly everything we’ve built.
Why it matters
Knowledge hoarding has a hidden cost. When people and organizations treat what they know as proprietary, they slow down the work, isolate the expertise, and create fragility. When one person holds the context for a system, a process, or a decision, that context walks out the door with them.
The open-source model offers a different proof. Software built in the open — where anyone can read, improve, and share the code — powers most of the web. It’s more secure, more resilient, and more innovative than most proprietary alternatives, precisely because it benefits from more eyes, more minds, and more perspectives than any single organization could assemble on its own.
That lesson doesn’t only apply to software. It applies to how teams collaborate, how expertise develops, and how trust gets built — with clients, with partners, with communities.
How we practice it
Four Kitchens started this way from the beginning. In 2006, the founders taught themselves Drupal from documentation the community had written and modules volunteers had built. The foundation they built on wasn’t theirs. It belonged to everyone.
That sense of reciprocity became an operating principle. Early versions of our values included a commitment to contributing to open-source projects every single day — not as a marketing claim, but as a standard for how we work.
In practice, that has meant contributing code back to Drupal, sponsoring camps, sending Web Chefs to speak at events large and small, writing publicly about what we’ve learned from complex projects, and documenting our work in ways that leave clients more capable after an engagement, not more dependent.
Our biggest contribution
The clearest expression of this value is Emulsify.
We built Emulsify because we kept seeing the same problem: large organizations — higher education institutions in particular — struggling to maintain consistent brand and visual identity across dozens of websites. Every institution was managing the design independently, spending significant time and budget on a challenge that was fundamentally shared.
We could have built a proprietary solution. Instead, we built an open-source design system toolset and gave it to the community.
Emulsify is a component-based design system that uses structured, reusable code to implement a visual identity across multiple websites. Because it’s built on components, design updates don’t require rebuilding a website’s look and feel — changes flow through the system reliably and consistently. The underlying code is tested, accessible, and built to last. It works natively with Drupal, with active community support and ongoing development.
For large organizations managing many sites, that kind of system isn’t a convenience. It’s what makes it possible to maintain coherent brand governance at scale without constant intervention.
Emulsify has since been adopted well beyond our own client base — active on more than 5,000 sites, according to the Drupal community. That’s not a side effect of open-sourcing it. That’s exactly the point.
Why every team should share what it knows
The organizations that benefit most from shared knowledge aren’t the ones that give the most away. They’re the ones that treat generosity as a discipline — a practiced habit rather than an occasional gesture.
When a team documents what it learns from a complex project, that knowledge compounds. It makes the next project faster. It helps newer team members build on real experience rather than starting from scratch. It creates the conditions for the kind of deep expertise that clients can actually feel and come to expect.
The same is true at the community level. The Drupal ecosystem is stronger because thousands of organizations have contributed back the solutions they built for themselves. No single one of them could have built what the community has built together.
Sharing knowledge doesn’t diminish what you know. It extends your reach, strengthens your relationships, and positions you as someone worth learning from.
Not a value we added
When we revisited our values in 2025, “Share What We Know” didn’t feel like a new commitment. It felt like a reclamation — a formal name for something we’d been doing since the first time we pushed code back to the community that had taught us to build.
Our goal has always been to do work that outlasts us. Tools our clients can extend without us. Documentation their teams can use long after our engagement ends. Contributions the community can build on for years. A website that keeps growing, improving, and reaching its audience without waiting for the next big contract to move forward.
That kind of lasting impact doesn’t come from holding things close. It comes from letting them go.
“Share What We Know” isn’t a value we added. It’s what we’ve always been.
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!