[KronisLV]

> ...grew out to become a worldwide multi-node adblocking DNS network with thousands of concurrent users around the globe… but that also meant more server load, which meant upgrading servers, more incident (reports) and as such more work. In other words; the project has become a victim of its own success.

Isn't this a problem that most hobbyist projects that get big have to deal with in some capacity? To me it seems like maybe a case of deciding between monetizing it somehow and having a business around it with multiple other developers partaking in the development/maintenance processes, donating/selling the entire project to some company or foundation, or pulling the plug as we see here.

[genzer]

This reminds of the journey of the creator of icanhazip [1]. He had created it and maintained it through several milestones _on his own_ until he could no longer carry on. Luckily it ended on a good note as Cloudflare decided to "buy" it.

[1]: https://major.io/2021/06/06/a-new-future-for-icanhazip/

[akuji1993]

Pretty much as you described it. And you can't blame these guys for one second. Who would pay hundreds, if not thousands of dollars for upkeep without getting any revenue from it.

Kinda sad that OSS and "community-friendly" projects like these mostly end up like this or bought and monetized. But it's totally understandable.

[rplnt]

> donating/selling the entire project to some company or foundation

It's not 100% clean service - you are arbitrarily blocking access to certain resources, so I would guess companies wouldn't want to be associated with it.

> having a business around it

For a service like this, it could pose a major breach in trust for its users. Maybe there's a business that doesn't involve changes in the DNS that I don't see.

[gunapologist99]

but people sign up voluntarily, right? So the users are actually the ones arbitrarily blocking their own access.

[MomoXenosaga]

What company would associate itself with blocking advertising? Worse it could end up like AdBlock plus.

[KronisLV]

Probably any that:

  - has resources for supporting a project like this
  - doesn't have any connection to the ad industry and therefore don't care for backpressure from it
  - views ads as a security risk and a vector for attacks (in addition to other questionable content) on their corporate devices

But you have a point about AdBlock Plus, which sort of sold out, if memory doesn't fail me. They had a good run, but nowadays i just use uBlock Origins.

[Maxburn]

Yes, but there seem to be plenty of competition in this space. Entering into that pool probably didn't look attractive.

[capableweb]

No, I think it's a problem of over-engineering and subsequently ending up with fragile systems. If the author had a service that didn't take up much time for them to maintain because of the various problems that appeared, they probably wouldn't close down the project.

One case worth mentioning: The Pirate Bay. One the of the largest websites in the world (or was at least), with the least amount of technical focus. The website hardly changed, never made the owners any money, they never focused on the technology but rather built the simplest thing they could for the smallest amount of money the could. They had the largest adversary at that time, but still, the website is up and running and basically been since day 1. I think their trick is that they never really cared about the technology itself, and only cared about making information free.

[KronisLV]

> If the author had a service that didn't take up much time for them to maintain because of the various problems that appeared, they probably wouldn't close down the project.

Is this even possible in our modern day world, where there are constantly breaking updates and security risks that need fixes (look at the recent log4j debacle, for example)?

Because while sites like TPB and even HN don't outwardly change often (for example, if the UI works it's generally left that way, without a redesign every year), there is no doubt that they still take attention and effort to maintain, keep running and more importantly, keep running securely.

Of course, if you're talking about the domain complexity (which you need to deal with) vs accidental complexity (which you introduce because of either lacking knowledge or chasing after the latest and shiny technologies), then i fully agree with you in that regard! That's why i rather enjoyed the "Choose Boring Technology" talk: http://boringtechnology.club/

[selfhoster11]

That really depends on your stack. A plain LTS Linux distro + bind9 + zonefile formatted blocking data + security auto updates is pretty hands off to me.

[KronisLV]

That's funny, because it's not unheard of for even simple unattended updates to break something, for example: https://blog.kronis.dev/everything%20is%20broken/debian-and-...

(the tone of that blog post of mine is a bit vitriolic and the advice isn't exactly serious, but the fact of the matter is that sooner or later things will break)

[selfhoster11]

OK, fair enough. I guess you can minimally complicate this by updating an exactly identical machine/boot drive first, and then immediately alerting if health checks fail on that. But it really doesn't seem that bad to me. I've run a VPS that's been self-updating continuously since Feb 2019, and I've not had many breaking issues with the OS.

[eptcyka]

This is a false premise. Supporting the same use case at different scales definitely comes at different engineering costs. The Pirate bay backend was using somewhat weird optimization hacks to support their load.