People are obsessed with solutions. But I think what the world often needs are not just solutions—but the potential to make solutions. If you can create an environment for other people to have interesting ideas that can succeed, that’s powerful. They can take their ideas and move forward with their own sustainable open source effort.

I got involved with Clojure in the summer of 2008, one year after founder Rich Hickey released it. I noticed that even though people constantly asked him for things, Rich would often say “no” and instead, empower them to find their own answers. He created that supportive, learn-as-you-go environment.

So I followed his lead and became the type of maintainer that sets boundaries and gently pushes back. Turns out, a lot of the things people think they need are solved by third-party open source projects that integrate with Clojure but don’t require changes upstream. If there’s a critical bug, I’ll say, “You can do this and I’ll help you.” I invest the time so that they understand how to fix it themselves in the future. And over the years, this mentality has built a community of very solid contributors who do non-trivial work in a relatively consistent way.

An early start and a connection with the creative world

In 1988, my dad bought an Apple 2GS. He was in the military at the time, not making a ton of money, so it was a big investment. “Make your own games,” he told me and my brother. So we found a book on Apple programming, Apple II BASIC, and then hounded Dad to buy the hardcover Apple II BASIC Programming Reference Manual. We’d make things, trade notes, have friendly competitions. My dad recognized that we loved games, and presented us with a unique opportunity to create from an early age—and it completely shaped our futures.

My brother develops games in Dallas, and while I went to undergrad for film and chose new media for grad school, I eventually got back into programming. I was naturally attracted to UI work because it’s about creating an experience. Just like in film and music, you have an audience and you’re trying to lull them into the magic of your world so they forget everything else.

I realized there is this continuum between art and film and music—in giving your audience a captivating experience—and doing UI work. If it wasn’t for the UI side, I may have never gotten into compilers and functional programming. And in the end, those are really secondary to my interest in building a great product.

How everything (slowly) fell into place for Clojure

Around 2004, I started working as a JavaScript software developer. When Google Maps came out in 2005, people saw JavaScript’s potential and were eager to hire JavaScript experts. I wasn’t really an expert, per se, but in about six months of coding against Firefox 1.5 and IE6, I learned pretty fast.

In 2010, I joined the interactive news team at The New York Times. Their stack was all Ruby on Rails on AWS, and no one really knew JavaScript. I did, but had zero training as a journalist. The New York Times newsroom quickly changed that. I didn’t have my own “desk,” but I’d work with the other desks—politics, sports, culture—and use my JavaScript and programming expertise to spin up special digital versions of each story.

In 2011, Rich Hickey and Relevance, a Rails consultancy, created the first version of ClojureScript, a compiler for Clojure that targets JavaScript. It was cool, and had promise, but needed a lot of work to make the user experience as seamless as Clojure in the Java Virtual Machine (JVM).

I got involved, not only because I knew JavaScript, but because I saw ClojureScript’s potential. Six months after its release, I wanted to add a feature and Rich loved my patch and immediately gave me commit rights. Over time, since Rich was starting Datomic and his crew was busy doing consulting work, I took the lead on ClojureScript. I would log into JIRA, garden the tickets, merge patches, look for contributors, and guide people toward things that needed attention. I became the de facto maintainer.

At the time, there were a lot of things working in our favor. Google developed V8 two years earlier; Apple was investing heavily in JavaScriptCore; and Firefox was ramping up SpiderMonkey with new virtual machine techniques. I recognized that the evolution of the virtual machine space for JavaScript would make ClojureScript viable. There was a very small community with some early success stories, and I knew if we played the long game, ClojureScript would become indispensable.

ClojureScript really took off with the introduction of Facebook’s React. Even though it looked object-oriented, React provided the first functional-friendly approach to UI programming. Amazingly, it took me two weeks to make my first prototype of a ClojureScript React integration. Within six months, all new ClojureScript work was effectively React-based, and the community doubled.

Slow and steady is better than fast and furious

Since then, we’ve reached a point where ClojureScript is sustainable and healthy. But there’s often this urgent push in open source to make everything easier, solve everybody’s issue, and scratch everybody’s itch. And we just don’t do that at Clojure. We empower people to fix their own problems, or start separate projects and integrate them. That might mean that the user experience has evolved at a slower pace, but it’s a scalable, maintainable approach that doesn’t increase the burden on the main source stream.

Generally, open source has a real problem with sustainability. You see so many people, especially younger developers with more free time and endless energy, who burn out after one or two years. Projects explode overnight and there are suddenly hundreds of thousands or even millions of users—and still just one person doing everything with no support. It happens way too often.

GitHub Sponsors could eventually lead to a better world where an open source maintainer generates enough income to bring on a second maintainer, and so on. Where strong contributors could also benefit from their hard work. Where a non-traditional organization is built around the project to ensure the people who support it don’t get burnt out. If we could somehow address the lifecycle in a more holistic way—if we could scale responsibility to enjoy the experience—that would be ideal.

A lot of what I do with ClojureScript is fueled by my own excitement: What contribution or improvement would make me happy? Prioritizing that over what would make someone else happy is important for maintainer satisfaction.

Stay true to your vision, and have fun

After all, this should be fun at the end of the day. With my music, I’m totally happy making a record that maybe 10,000 people like. The same goes for open source—you create something great together, and a lot of people can enjoy it. ClojureScript isn’t my full-time job, but I’m still pretty active. My strategy is to only work on ClojureScript when I have the excitement and energy for it. For example, when I used to travel or attend conferences, I would have a 48-hour window to go crazy and do something big.

So why work on project A versus project B? Or why take that job instead of this one? It should tickle something in your mind. A lot of what I do with ClojureScript is fueled by my own excitement: What contribution or improvement would make me happy? Prioritizing that over what would make someone else happy is important for maintainer satisfaction. Because chances are, if it’s good enough for you, it’s good enough for a lot of people. And if someone else thinks something’s missing, they can fill those gaps on their own.