I created a tiny startup in Haskell which failed RIP. I decided to open source the code though.
21 Likes
I’m sorry to hear that your startup didn’t make it.
Thank you for releasing the code and, even better, your descriptions of your CI setup and other documentation. I think that is very useful community contribution!
11 Likes
Thanks David. Also thanks for your great leadership of HF!
4 Likes
Thank you! And sorry it didn’t work out financially. Do you want to discuss here what you (and possibly others, if you have already heard feedback) think why you couldn’t find enough paid users? I’d be very interested.
3 Likes
Yes, I’m aware of that. For example, you wrote:
I think the key reason to understand why Deadpendency is not successful is to understand that all development teams are extremely time poor (unless they are being greatly mismanaged).
I was surprised about that, and was wondering what you would think about other reasons, for example:
- The trial period might be too short for people to start depending on your tool
- Developers liked and valued it, but management didn’t understand it and didn’t pay for it
- It was too expensive
- Its reporting was flawed in some way, e.g. false positives, false negatives
- No support for some popular languages & ecosystems like Elixir, Docker, Github Actions, …
- Not enough added value in comparison to existing tools like Dependabot, or the added value was not advertised sufficiently
But these are all just wild guesses, I’m wondering whether you have more insight.
1 Like
Unfortunately I don’t really have any hard info as I did not want to spam email people who uninstalled as to why. It would be great if Github Apps supported an uninstall link that could load when people remove an app, where I could solicit feedback.
I guess I had tried everything I could think of to improve or promote the tool and the pattern of people not keeping paid installs was very clear. It is also not to say it could not have been successful, but it was unlikely to be successful to the degree that the work required would be worth it.
The tool was $10 a month (to a company this is nothing) and did all kinds of dependency project health checking that I could think of. There were other options to add, like how long does it take for a PR to get reviewed or commented on. However, these were even weaker indicators of a lack of health. Overall, my reflection is that all ecosystems have a lot of unhealthy packages and I continually tuned the defaults to be less sensitive otherwise you would be inundated with ‘dead’ dependency warnings. The default fail level for lack of a version bump for a dependency was 2 years!
So in short, I think it did what it said on the tin and it was cheap. More language support does not really matter, unless for some random reason it goes viral on those languages. The 13 languages it does support is definitely pretty good.
And I guess I also decided the concept of dependency project health tracking was not worth it. When I started it I thought advanced teams with things like automated dependency updates could benefit. Now I do not think so. As I mention in the blog post, I would spend the time doing manual investigation of a deadpendency report on writing more tests to insulate the application against old (or new!) dependencies causing problems.
If you think there is some missing key feature I’d be interested to hear it!
3 Likes
Thank you for releasing the code but more importantly the writing you did around choosing libraries, platforms and the devops process. They are invaluable for someone wanting to use Haskell in anger.
I am sorry your startup had to shutdown, it seems like a useful automation tool to have.
3 Likes
I see, thanks! Yes, for 10 dollars a month it’s definitely not too expensive. For me at work the reason was lacking Elixir support. For my hobby projects in Haskell I didn’t understand how it related to cabal outdated (and anyways didn’t see the need to automate dependency tracking yet).
1 Like