After one year I’ve decided to discontinue supporting Code Dog for BitBucket Server and GitLab Self-Hosted. Here’s why.
Code Dog Server
After my initial success with Code Dog Cloud I thought it would be smart to respond to market demand and add support for BitBucket Server and GitLab Self-Hosted - and so I did. But now, after over a year, I understand just how difficult supporting a product like that is. Not just for me, but for the user as well.
A nightmare for the user
To set it up, the user had to:
- Download it
- Create a Slack App
- Configure SSL so that Slack.com can connect to it
- Create a new BitBucket/GitLab user
- Configure access to BitBucket/GitLab
- And lastly, configure Code Dog
All that just to try and see if they like the app.
A nightmare for me
At first I distributed the app as an executable, but it turned out a lot of people considered that “insecure”, and still more didn’t have a Linux server available. I switched my distribution to a Docker image, but even then I received email after email asking me how to run it on Windows or an environment I was not familiar with.
But that’s not all. To make it work I had to support Slack, BitBucket and GitLab.
Slack is not that bad - the documentation is good and the support is exceptional. However from time to time they will introduced new features or make changes that required me to spend a day or two coding. One such example were private channels.
Additionally, to create an app, the user needs to do a lot of pointing and clicking, maybe half an hour. Next he has to copy all the necessary keys and IDs to Code Dog to make it work. And then he needs to enable SSL so that Slack.com can connect to it.
This caused an endless stream of emails asking me “where do I find the App ID” or “how do I configure SSL”.
Don’t even get me started with BitBucket. The Self-Hosted version is a completely different tool from the Cloud version. Even their API is different! And it’s so unimaginably slow. If an instance has more than a few hundered repos it would take minutes to communicate with it, resulting in HTTP timeouts. I’m grateful to the users that helped me debug it and I’m really sorry to let you down by discontinuing the product.
GitLab has a lot of bugs and is not app friendly at all, it’s like they weren’t aware apps were a thing when they designed it. Luckily, the Self-Hosted version uses exactly the same code as the Cloud version so my job was easy. Still, integrating with the app and configuring webhooks was so frustrating that few users finished the setup.
My breaking point
After yet another email from a user asking me how to solve a problem with the Slack API (they were getting a mysterious
missing_scope error) I sat down and tried to understand what was happening.
As I was slowly digging into the problem it began to dawn on me that catching up with API changes, library updates, and UI “improvements” is making my life miserable, and given the low return on investment it’s not the best use of my time. I gave up.
What will happen to the Cloud version?
I’m still working on the Cloud version. I can immediately catch errors, I have access to all of my debug information, and I can deploy a new version within five minutes. I’m happy with it.
What will happen to the code?
I no longer wish to support it, but it’s good code. If you wish to buy it please contact me at firstname.lastname@example.org.
An indie maker should never attempt to tackle the standalone app market. The amount of energy required to support it is incomparably larger than supporting a SaaS product.
There is a reason why there are so many companies that specialise solely in supporting Atlassian products.