Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Zombocom Problem

newsletter.squishy.computer

Post reply on HN
Print view View original

31–40 of 83 posts

Re: The Zombocom Problem

#31

Post by kragen »

CobrastanJorji wrote: post #29

This may be a bit of an old allusion, but Lotus Notes is a great example of this. Notes is fundamentally a programmable, non-relational, client/server replicated database with a UI on top of it. It's a workflow engine for accomplishing whatever business processes a company might have that can be made to keep working pretty well when the client computer is offline. It can be anything. But it is remembered first and fo…

I have the vague memory that it was a distributed reimplementation of PLATO Notes, which had otherwise similar capabilities but was born as a bug tracking system?

Re: The Zombocom Problem

#32

Post by benatkin »

spencerflem wrote: post #26
benatkin wrote: post #18

While I’m not quite sure what we’re talking about here in terms of platforms, I’ll mention a couple of personal and team server platforms that are subject to the Zombocom Problem and a couple that aren’t. WordPress, NextCloud, and OwnCloud try to be all you need and even though they have plugins they seem subject to the Zombocom problem, because stuff gets shoehorned into a particular app. On the other hand there is…

Sandstorm's architecture is incredible, and I love it a lot. In my opinion though, it did kinda fall into this. It was an extremely secure and well thought out way to run concurrent user web apps. But none of the apps there were better than the proprietary Google suite or equivalent, and for self hosters, the need to explicitly port the app vs the simpler but less secure and less integrated 'just run a docker contain…

They chose apps that had personality. For instance, one of their flagship apps, Rocket.Chat, had a slash command for lenny face. https://docs.rocket.chat/docs/slash-command

This was good, and goes against the Zombocom problem.

However, as you said they didn't address self-hosting as well as they could have. I don't think it was because of other domains, but because they were envisioning people sharing them or paying for a cloud host, and didn't try to emphasize only apps that don't guzzle CPU, memory, or storage. Rocket.Chat is a MongoDB app. GitLab is another one: https://apps.sandstorm.io/app/zx9d3pt0fjh4uqrprjftgpqfwgzp6y...

Similarly on Dokku you wouldn't have apps sharing a database instance. If you had two apps that needed a database, you'd start two postgres instances.

I don't think they ever failed to see the Zombocom problem or attempt to avoid it. Curating apps for security made since. However, it didn't see enough use for them to add lots more apps to their library.

Re: The Zombocom Problem

#33

Post by theamk »

This seems very similar to concept of Architecture Astronauts [0].

I am glad author is realizing this is bad! They state their goal is to build a system that is "pliable, re-shapable, open-ended, true to its materials as a universal machine" which is as close to zombocom as it gets.

[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Re: The Zombocom Problem

#34

Post by creamyhorror »

This was previously phrased in startup advice as "start with a single vertical and generalize afterwards", "don't try to boil the ocean", etc. A lot of less-experienced entrepreneurs start with wanting to conquer all markets with their new paradigm, but the truth is you first need to capture specific segments/verticals or you'll be spread too thin.

Similarly, with a software solution, you need to make it integrate into an existing stack used in the market, or else build the layers to make it something that can fit neatly into a business's processes. E.g. if there's already an established market for engines or frameworks, then a business can use your conforming engine almost plug-and-play. Otherwise you have to build the app and UI layers on top to make it end-user-facing.

Once you've achieved some success in a vertical or layer (e.g. appointment bookings for salons), you can abstract the core solution/framework and start applying it to other verticals or build adapter layers to start attacking other layers (e.g. appointment bookings for everything).

Re: The Zombocom Problem

#36

Post by spencerflem »

benatkin wrote: post #32
spencerflem wrote: post #26

Earlier quoted context omitted.

Sandstorm's architecture is incredible, and I love it a lot. In my opinion though, it did kinda fall into this. It was an extremely secure and well thought out way to run concurrent user web apps. But none of the apps there were better than the proprietary Google suite or equivalent, and for self hosters, the need to explicitly port the app vs the simpler but less secure and less integrated 'just run a docker contain…

They chose apps that had personality. For instance, one of their flagship apps, Rocket.Chat, had a slash command for lenny face . https://docs.rocket.chat/docs/slash-command This was good, and goes against the Zombocom problem. However, as you said they didn't address self-hosting as well as they could have. I don't think it was because of other domains, but because they were envisioning people sharing them or paying…

Slack has /shrug which isn't that far off.

Idk though, I stand by it. Any company that wanted a chat app could get slack or skype or teams instead, and they are backed by a big business who assures they're safe, come with desktop apps that have pop up notifications, and were quicker to boot up, and frankly are better.

And, personality or not, any app that was ported to Sandstorm you can still run off Sandstorm too.

The killer features are one single account for everything (ala Microsoft's suite which also has that), the potential for some very cool interoperability that never quite reached its full potential, and better security, which not enough people/companies were willing to sacrifice other desirable traits for, apparently.

Re: The Zombocom Problem

#37

Post by janalsncm »

I have taken this approach with personal projects as well. In the past, I divided up the functionality into a bunch of neatly-organized classes at the beginning and then implemented each one in separate files. Big mistake. Much better is to put it all into one, ugly file until the kinks are worked out and then organize it later, at least in my opinion. It’s also much better for working in a flow state so that I don’t have to switch between 8 different tabs.

So even for personal projects, what’s most important is the ugly MVP that does the thing. It’s only after that works that I clean it up.

Re: The Zombocom Problem

#38

Post by alganet »

From the technical perspective, I see Amazon as a platform first design. They're not shy about it, they embraced it ("we so totally overengineered our infra we now can rent it!"). It's so zombocomey that you can use it to zombocomify your own shit.

We should still call it "overengineering" and not "insight". It was a risk and a compromise.

Re: The Zombocom Problem

#39

Post by lelanthran »

EGreg wrote: post #15
resonious wrote: post #10

Earlier quoted context omitted.

I've also noticed this. Seems rare to find successful frameworks that were actually built out as a framework from the start.

Here are two that I worked on for 10 and 5 years, respectively: https://Qbix.com/platform https://Intercoin.org/applications Maybe I was just a crazy socialist LOL Here is the why: https://intercoin.org/community.pdf https://intercoin.org/IntercoinSolutions.pdf

You think those are successful?

Re: The Zombocom Problem

#40

Post by codingdave »

CobrastanJorji wrote: post #29

This may be a bit of an old allusion, but Lotus Notes is a great example of this. Notes is fundamentally a programmable, non-relational, client/server replicated database with a UI on top of it. It's a workflow engine for accomplishing whatever business processes a company might have that can be made to keep working pretty well when the client computer is offline. It can be anything. But it is remembered first and fo…

That is kind of how it went, but there was more than email in its early days. Email existed, but Lotus also sold a separate email product. The rumors at the time ('94) were that Lotus was going to remove email from Notes and focus on apps. But instead IBM bought both and merged them. It got kinda lost from there, while also getting way bigger, but that is a different story.

Even so, it did have some app templates that came with it back in those early days - a helpdesk ticketing system, a sales CRM, discussions. I forget what they all were, but there was definitely a base of examples aside from email for people to start with.

Post reply on HN