I'm here to spark a discussion on a topic that, I believe, many of us have encountered but might not often talk about: projects that we were excited about and believed in, but that ended up failing miserably after release.
To kick things off, I want to share my own experience with a project called interfAIce. It's a Java/Kotlin library that allows developers to access Large Language Models (LLMs) by defining interfaces. The library automatically generates proxies that query the OpenAI API and formats the results into the defined return type data. I thought it was super cool at the time of development.
Despite my enthusiasm, my library never gained the attention I hoped for after its release. Reflecting on it, I believe the primary reason might be the mismatch between the technology stacks used by Java/Kotlin developers, who are mostly in server/mobile development, and AI developers, who predominantly use Python or C++. Of course, this could just be one of many reasons it didn't succeed.
This experience left me pondering, and I'm curious to hear from you all: What projects have you worked on that seemed promising or even groundbreaking during the development phase but didn't succeed in the market or with users for one reason or another? What was the project about, what made it seem promising initially, and ultimately, what led to its downfall?
More importantly, what do you think were the reasons for the failure? Was it a matter of timing, market fit, execution, or perhaps something else entirely? How did this experience influence your approach to future projects?
I believe that by sharing these stories and the reasons behind the failures, we can provide valuable insights and lessons for all of us, especially for those in the software engineering and development fields. It's a chance to reflect on the unpredictable nature of tech projects and the importance of resilience in our industry.
Looking forward to hearing your stories and learning from your experiences!
A few years later, Slack comes along solving the same problem in a different way, and now platforms like that are the overwhelmingly popular choice for group communication.
The reality was it just enabled a flood of crap onto the delivery apps.
The sad fact is that this doesn't really work: if the project will only work because you have high expectations of the general public, it will inevitably fail. Creating a community like HN that has a reasonably-high quality of participants is incredibly difficult.
On the other hand i did gain some fulfilment while building my projects, sometimes learned something and sometimes even earned some money in a different way
The saddest thing to me is the really innovative stuff, the preset and customizable audio filters -- which would work even better now that earbuds have even more microphones and processing power than they used to -- have yet to be replicated on any newer hardware because no one seems to be interested.
Nobody, even in that community, wants to use a tool to explore the trade space of highfleet ships - but I realized that was probably a niche case. And people are happy pasting their ship files into discord, getting 3 reactions, and never having anyone download them.
I think if discord had "download stats", nobody would use it to share things, given it is incredibly transient and impossible to search.
I thought I had stumbled upon a new and better way to do universal data compression. It was promising because I built a functional demo that beat (as measured by compression ratio) the native zip tool on Mac, Windows, and Linux, and even beat LZMA - all by a wide margin.
Fundamentally, the project failed because it was not actually able to universally compress data. The technical concept is most easily described as attempting to produce an algorithm that would offer close to the Kolmogorov complexity of the desired data, by rapidly changing the structure of the algorithm, the logical and mathmatical operators within the algorithm, and the initial values of the variables in the algorithm - i.e. attempting to brute-force something close to Kolmogorov complexity, which worked about as well as it sounds like it did: extremely well (better than alternatives) for already small, already extremely low-entropy files, and somewhere between "horribly" and "not at all" for everything else.
Trying to build it made me a more skilled developer, allowed me to learn more then I ever would've guessed I'd known about the Pigeonhole Pinciple, Kolmogorov complexity, information theory as an entire field, etc.
However, this one also made me a much better person. Bringing this project up to a colleague resulted in a book recommendation. That book helped to shine a spotlight on some subconscious racial views I formerly held that were unhealthy, but that I was unaware of, and being made aware of them allowed me to work past them.
It had so much going for it, but it was DOA from launch for two reasons: first, the implementation is so bizarre that the kernel documentation is frequently mistaken for an elaborate joke, and second the founder's racist blog went viral at virtually the same time as the public launch. It's not technically failed I guess as it's still being developed and does work, but a network without a network effect can only go so far.
I honestly think the "personal server" idea would be incredibly useful, and it would also be very profitable (not the software itself, but for cloud providers) if every suburban family rented a $15/mo VPS. I post about it here from time to time in the hopes that someone will fork it or re-implement what is basically a great idea, but in a non-ridiculous way and without #cancelled taint of the founder. Bezos, if you're reading this, please put a small team on it just to see if it goes somewhere, I'll be your first customer.
Stadia's shutdown was a great loss in the gaming world.
Its social elements were ahead of their time, allowing for unprecedented levels of interaction and connectivity.
Other platforms are still catching up to how easy it was to jump into a game with friends, share game states, or even stream your gameplay with the press of a button; no queuing.
Unfortunately, much of Stadia's potential was undercut by Google's marketing strategy :(
Colloquially, I don't see the 24-hour system going anywhere of course, but we long ago abandoned the concept that 12pm is actually solar noon with the advent of trains (at least, for the vast majority of people). Imagine not having to have to figure out the tz db just to log a time consistently referable from another perspective. What a beautiful fantasy!
Of course, it was still saddled with the Julian calendar, but that's probably going to take interplanetary commerce to see much benefit or traction.
I still love the language, and maintain my SSG that was written in Ruby over a decade ago. Shame that it's nearly dead now.
Such a shame that they closed this; even more shame that they didn't open-source this too.
The starting point was I disliked React's complexity and its violation of the implicit contract of the web platform in that HTML, JavaScript and CSS should function as the standard, if they're going to look like the thing. By creating a parallel but subtly different HTML/CS/JS DSL, to me it corrupted the platform and weakened it overall. I thought it a flawed approach and still do, and longed to see something better, so I built something that had the ergonomics I wanted.
I also really liked the things that came along like HTMX, Stimulus, Hotwire, htmz, etc. That I saw as giving power to the platform by using its technologies, along the "web grain": https://frankchimero.com/writing/the-webs-grain/
I hoped my frameworks would take on React, but I came to see there's more to tech than superior tech. It's about tribalism, too. Similar to beta vs VHS. Even tho React and Angular are inferior in many ways, the have the distribution mechanism, brand recognition, and "choice safety".
Ability to hit the ground running is oft-touted but I think it's less important than people think in front-end. Any really complex app ends up having to do its own weird stuff, that is non-intuitive respective the framework of choice, so hiring devs that "know React" is not super important as long as they know the front-end.
I think framework's are also about marketing. You can't just have superior tech, you need a pretty looking website, a catchy name, good design, too. But even if you have those things, it's no guarantee.
For me it would have been nice to have people adopt it -- tho perhaps it was not the kind of thing I would like to be maintainer of? I prefer products, like the successful ones I'm working on -- but the main thing was, and still is, that it is nice for me to use. It wasn't the only reason I created it, but it was the main reason: that I wanted a tool that I can use, and liked to use. And I created that, and still use it.
So it's successful like that, but not in terms of people using it who are not me! Tho, thanks to the popularity of some of the products (that we make) it's used in, it's install numbers get a boost because it's a dependency of those.