I’ve been building Derw alone since sometime last year. Recently, someone asked if I was working on with others - and the answer is no, and it’s kinda intentional.
As I touched on in my last post , the community is something I’m planning to build once I get to 1.0.0. But what about building a team? Languages like Roc managed to build a team even before the repo was public, with several people contributing 100+ commits. I think that’s super cool - and I’m a strong believer in making things better by working together . That said, there’s benefits to avoiding working with others directly.
Working alone means you don’t have to share the context of your changes with others. It doesn’t mean that you don’t keep track of changes that you have made, nor that you don’t report them. But if there’s a change I wish to make, I can do so without consulting others. This is particularly useful, for example, when I want to rewrite a file from TypeScript to Derw. No collisions with other PRs, no need to warn anyone “hey I’m going to rewrite this file”.
You’re able to keep to your own schedule, and adjust it as necessary. Everyone has their own priorities, and without waiting for someone to finish something and without someone waiting for you to finish something, you’re able to move at your own pace. End users will have an impact on that timeline, if you listen to them, but when you’re working mostly on your spare time, it’s important to be able to take some days off and go play games instead.
Work teams go off and have workshops and meetups and parties to discuss their vision for the product they’re working on. In open source projects, you don’t have that luxury. Visions and plans have to be communicated in text, and often falls second place to just working on the vision inside your head. Shared goals have to be established through long conversations and RFCs. Working alone you don’t need that to the same extent: if you intend to have users, you need to tell them roughly what your goals are with a project, but you don’t need to have a back and forth discussion on a feature. You can just build it. That isn’t to say that other people’s visions for your project isn’t useful - nor does it mean that you never need to discuss a feature with someone. But you can do that on demand, as needed, and that makes it easier to execute.
If one of your goals with a project is simply to learn, when you build something alone, you have to learn all the awkward parts as well as the familiar parts. You might only have used webpack in the past but your project is more suited to esbuild. You’ve never had to interact with garbage collection in Node but to get the performance you want, it becomes relevant. A team can help steer you with their collective knowledge of all these random pieces, but self-learning can work just as well.
Some view development styles like Elm’s as a flaw, that working in mostly isolation defeats the point of open source. I don’t see it that way: a creator with a strong opinion and direction leads to a purer, more cohesive creation. It might not do everything the community wants, or it might implement things in a way that someone did not prefer. But early on into a library, framework or language’s lifeline, it is especially important to have a driving force, someone who can see where they want to take it - and act on it. Later on, it may make sense to share that load and become a Python-style BDFL. Early on, being pulled in multiple directions can fragment both the vision and the implementation.
With Derw, I will likely stay working without a core team for a good amount of time - probably past 1.0.0. I can make all the different features like built-in testing, built-in formatting, multiple target languages and package management work in a Derw-like way because I have the context of what I want Derw to be, and how the pieces should fit together. Eventually it will probably make sense to onboard others who can contribute along the line my own vision, but I suspect that will not be possible for a while. I still reach out to people when I have an idea I want to discuss: coworkers, friends, chat, Twitter. These inputs are great, and valuable, and have led to several nice aspects of Derw. But I can take this collective knowledge on a specific feature and implement it myself, and that’s likely the best way for a new language.
Like this post? Follow me on Twitter to stay updated, star Derw on Github, or sponsor me on Github to help support my work.