How does a developer experience (DX) enhancer open-source tool live and grow?
Kool has existed as an open-source tool for more than 3 years now. As an idea, it had been cooking within our team since a few more years before - in the old days of using shell scripts to improve local environment management with virtual machines. We all know there should be a better way for all of us web developers, a way to stop struggling every time we need to set up a new project environment.
We would like to write more about the process we are going through as an open-source project - as we like to call it - our journey! This could be the first of a series of future posts, that perhaps can help inspire someone to get out the door with their own projects. By throwing a light on our history we hope it endorses
kool even further as a project worthy of your attention and perhaps its adoption.
From software houses to single-product startup teams, the need to work with more than a single project in different stacks is ever more usual. The DevOps space grew out of this scenario and the intrinsic need for operations to handle such workloads going to production - and it also encompasses the efforts for improving the development life cycle as a whole.
As many many teams out there we ended up building out our own flavor of helper tools to facilitate and optimize the daily routine engineers on our team had with constantly projects switching while aiming to keep that as close to future production setups as possible.
Docker is the most popular container engine out there. We love it and it empowers us to solve a lot of problems. We heavily rely on Docker (or possible in-place replacements like Podman) to work out the complexities of local environments for web development.
But Docker is a container engine at its core, not a development environment tool - although the good team at Docker is aiming to achieve this with more developer experience-directed solutions nowadays.
Still, our in-house solution felt worthy of the hassle of taking it out to the world - we didn’t create a tool to provide an experience, we extracted the experience that is supported by the tool. That is our vision, developer first and pragmatism all the way towards good and healthy developer experience when working with locally developing web applications.
Our tool is built on Golang due to our solid past experience with the language, and of course that is the go-to choice for a lot of prominent CLI tools (
terraform just to name a few).
We looked upon our creation, and it was good
After having built and used it daily we were leveraging the benefits of our creation, it was clear the gain and benefits for our software house with a couple of dozen developers with multiple projects to remove the friction amongst teams, onboarding new members, and project context-switching.
Given our networking with other tech companies (partners and clients in Brazil and abroad) - once we presented and they learned about what we created the feedback was very encouraging. That was the validation we needed to take it to the next level.
Getting out the door
If the solution we made was helping ourselves and our peers, then we decided it was time to invest to make it available to a broader audience, and perhaps it could help them too. Most teams and developers could benefit from it just like we did.
We have since worked on the documentation and our website and planned the language and proper method to put ourselves really out the door into the wild, wild world. This has been a longer (or slower) process than we initially imagined or wanted, but all things considered, it’s the way it has to be given our other responsibilities.
We take the tool wherever we go ourselves, finding mostly positive feedback, and the most important and continued validation for us is that the content we have created and published so far organically brings new potential users to experiment with Kool.
Getting people to notice
How to get people to learn, assess, and finally adopt your open-source tool? That is a question few can answer properly, I guess because there is no single answer to it.
We started writing a few content pieces in our blog, and then after we felt the documentation was good enough, we took a step toward publishing these writings to a broader audience. Our first choice was Dev.to and we can say, it really surprised us in a very positive way.
Our first article was targeted at running Laravel with Kool, and our second published piece was a more general presentation and arguments why Kool exists and you should consider it.
The response to these articles was great. Together accounting more than 33K views and +500 reactions! That brought us:
- Going from around 60 to 600+ stars on Github.
- People creating issues for new features and volunteering to contribute.
- People joining our Slack channel and interacting.
- A few passionate and positive devs getting in touch just to express they very much liked our job!
As so, we are now officially - in our hearts at least - a proper open-source project with a growing community.
Moving forward (or going up)
Being a side hustle for us since day 1 obviously, we end up feeling like we are not putting in the time and effort necessary most of the time in order to grow as we envisioned. Making an open-source project viable in the long run is really challenging business. We are happy we didn’t give up at any time, but we feel the need to format it in a way to becomes sustainable to guarantee the resources for its continued development.
Here is what the “going up” in the title will make sense - we are going to offer a paired solution for moving your local development environment to the cloud in a PaaS fashion, deploying your containers with ease and efficiency as it should be. We plan that this potentially freemium service is going to be the catalyser for us to keep focus and investment on the open source project making it viable in the long run.
We must continue documenting use cases, and support more stacks and frameworks with easy-to-start recipes, so we can help a lot more developers in their daily jobs, being more productive and especially healthier when dealing with the Ops part of DevOps. And then we will be able to offer the Kool Cloud service on top of it, hopefully helping people around the world to work with web applications deployed in containers to production in a way they would expect it to be - simple and solid.
If you like Kool or just found our history at least interesting you can stay tuned via our channels:
- Register at kool.dev/cloud for earlier access to the cloud services we have been cooking.
- Join our Slack channel and join the conversation (contributing, using, testing, suggesting).
- Show your support by starring our Github repo kool-dev/kool and watch the repo for updates.
Thank you all who participated in any way so far in our journey - both the love and the critique, all very constructive and most valued to keep us true to our goals.
We have a long road ahead. Let’s make it a kool journey!