Sponsorship, open source, and the career dream
With these difficult times for many companies, I find myself reflecting on my future. There's a couple of obvious paths: the first is to continue in my corporate career, hopefully becoming a CTO again. I love my job, which is a great mixture of solving big scale problems, and enabling my team to solve them. The second is much more difficult to reach, but has been a dream of mine ever since I was a kid: to work full time on open source.
There seems to be a few ways of obtaining a full time open-source career. I won't go into them all, just the ones I've most familiar with.
A company might hire an open-source developer to work full time on their project. This model has a few benefits: a stable salary, direct contact with users of what you make, a "regular" job working on a project you love. It has some downsides too, like the position likely only existing while what you're working on has direct value to the company, or the pressure to work on issues relevant to your employers.
An open source developer might turn their project into a company, funded either by investments or by contracting with users of the company. That way they have full control over their employment status, but are under the whims of the investment environment and chasing contracts. If you have the time and energy to run a company on top of your desired work on open source, that could be great. Alternatively it's possible to bring someone onboard to run the more business-y side of things, but that comes with all the complications of either finding a "co-founder" or finding some consultancy to help you. Several of the bigger open source projects followed this approach - where the contracts in question would be support contracts. Provide the software for free, provide paid support.
An open source project might be funded by companies by commercialising - offering the project for free for individuals or small companies, but charging a fee for larger companies. This would seem to make a lot of sense since large companies have plenty of resources, but on-boarding individuals for free is an important key to getting companies to adopt the software. However, from what I've seen, it tends to alienate people unless the software in question is particularly vital.
Finally, there's the donor model. An open source project opens for donations in some form - either directly via email, or using some service like Github Sponsors. Companies might donate to ensure that the project keeps running, individuals might sponsor because they like the project. This is not completely stable, as needs in the company might change, but it's the most freeing in terms of the business side of things. A developer is free to choose what they work on. With Github Sponsors, it's possible now to set different goals and rewards - similar to other crowd-sourcing platforms.
It's also worth considering that open source projects accrue costs beyond people costs - hosting, domains, CI / CD, going to conferences, meetups, etc. A lot of costs can be handled cheaply - there's lots of discounts out there for open source projects if you shop around a bit. These costs are pretty project specific, since some can using existing infra like NPM, but others might need to do something complicated and costly like hosting packages themselves.
I've worked previously in companies where the majority of what I worked on ended up being open source. At my current company, I'm leading the initiative to open source as much as we can - including funding projects. I think the best output for open source projects comes when the developers are in direct contact with users of their software. If a project is developed in isolation, then it won't fit the needs and requirements of the users. For this reason I think one of the models where some form of support is provided by the creator to the funders - either as a contractor, support as a sponsorship deal, or in-house at a company using the software.
For Derw, I'd love to get to the point where I can work on it full time. I've managed to do a lot since I started, working in my spare time. But there is so much that could be done, if I could work on it full time. There's multiple ways of getting there, but I think for now the best models for me are either working within a company as a dedicated Derw dev, or through enough sponsorship that would enable me to work full time comfortably.
So with all that in mind, if you like the idea of an Elm-like language that aims to be more pragmatic, with interop for TypeScript and JavaScript, come sponsor me. Or if you're a company that'd like to invest more, feel free to reach out over at noah.hall@hey.com or on Twitter.
Footnote
Since starting Derw, solely in my spare time, I've implemented:
- A compiler in TypeScript
- A 55% rewrite of the compiler in Derw itself (self-bootstrapping)
- Type checking
- A language server with a vscode extension
- A syntax extension for vscode
- An automatic formatter (+ vscode extension)
- Output formats including TypeScript, JavaScript, Elm, English and Derw
- A package manager solution
- A performant, small sized download library with hydration for writing web stuff
- A standard library
- Libraries for GeoLocation, IndexedDB, LocalStorage, WebSockets
- A test runner
- A benchmarker
- A bundler
- A Gitbook explaining the language and how code is generated
- A tool for generating Derw templates
- Over 1800 test cases
But there's so much more that could be done. In my current plans:
- Optimizing the web library even more
- Typeclasses
- Better error messages from combining the TS language server with Derw's
- A better package management solution
- Finish the Derw compiler rewrite
- Optimized output builds of TS/JS
- Better server side code
- Flesh out the standard library more
It would be amazing to be able to dedicate more of my time to these things. Derw is used in production right now, so it’s all production ready, but more can be done!