When I look back on the side projects that I started and abandoned over the past few years, and the notes and drawings that I added to my notebook, a clear pattern emerges. Some ideas got way more attention than others, and a handful actually came up again and again. I would spend a few weeks thinking about them, eventually putting them away, but a few months later they always returned.
In one way or another, these ideas were all focused on my experience as a software developer. As I was working on other projects, I always noticed things that could be easier or better. More efficient CI workflows, better local development environments, automation to help manage open source projects. Eventually, I would always get so fed up that I wanted to build a tool that would solve that problem for me.
A few times, I did start working on such a tool. But I never made a plan, set boundaries, or defined a goal. And as I got deeper into the problem space, I realized what else was possible. How this tool could be so much more than I initially thought. But as I enjoyed jumping from idea to idea, the scope of the projects grew in so many different directions that it would ultimately cause them to fail. I was more interested in intellectual stimulation than delivering something of value.
I don't know why and when, but this has changed recently. I feel like I did enough experimentation, and the next big thing for me to learn is to deliver and then operate a product. To talk with other developers and teams, and help them improve their workflows. This is the fundamental idea behind my new project, DEV x BOTS.
Automatons – Automation for Developers
The focus of DEV x BOTS is the development of an automation platform for software developers called automatons. Looking back at my failed ideas and projects, they were all trying to automate various parts of the software development process. But building bespoke automation is time consuming work, and it really shouldn't be.
Learning from past mistakes, the project is set up to deliver small, concrete results that build on top of each other. While the ultimate goal is to deliver an automation platform, the first step is to create a library. Then I want to create a few custom GitHub Apps, finally building some of the ideas that have been floating around my notes for years. Any feature that the apps need will find its way back into the library, slowly growing its scope and usability. And the apps need to run somewhere, which means another deliverable is a runtime for them. The combination of library and runtime will be the minimum viable product.
I expect to learn a lot during this process, which will influence the future direction of the project. But in a nutshell, I want to broaden the feature set of the framework and move away from bespoke apps. Developers should be able to automate workflows that go beyond just GitHub, for example integrate their project management in Linear. And creating an automation shouldn't involve a custom GitHub App, but maybe just a configuration file in a repository. Which would be cool to create using a visual flow-based builder, similar to Blueprints in Unreal Engine.
All of this will take time to build, which is why there is a focus on small steps and iteration. Slowly working towards the minimum viable product, and then figuring out the necessary features for a simple, lovable & complete product.
Committed to Open Source
The automatons framework is developed as open source, and the goal is to (eventually) offer self-hosted runtimes so that teams can run the full stack themselves. Check out DEV x BOTS's GitHub profile and the project:
Besides just being a fan of open source myself, I am doing this for three reasons:
- Developers should be able to trust the tool. This means that they can inspect the source code and ensure that it is safe to run.
- Developers should be able to rely on the tool. With open source, they will always be able to run the tool themselves, no matter what happens with me. There is no vendor lock-in, and less of a bus factor.
- Developers should be able to contribute and solve their own problems. My priorities might not be your priorities. But with everything being open source, you can solve your problem and contribute the solution back to the community.
The commitment to open source also covers the usage of the platform. I will run an instance of the service that open source projects can use for free. But contributions to cover the development and server costs are greatly appreciated:
https://github.com/sponsors/jdno
Next Up
The next blog post will introduce the automatons framework itself, and the considerations that went into its design. We will look at its core library, and the prototype for an GitHub App that uses it. Until then, take care and have fun!
- Blog: https://jdno.dev
- GitHub: https://github.com/jdno
- Twitter: https://twitter.com/jdno_dev
- Twitch: https://twitch.tv/jdno_dev
Top comments (0)