This “Cambrian explosion” is exactly what we’re trying to help with at Monolist (https://monolist.co).

The number of tools used daily is growing, which is in one way beneficial for the worker since they get a better and more specialized tool to do their work. However, it increases fragmentation and the chances of missed work.

Email is the most common solution, but that has its own downsides and seems to be used less and less for daily work. We think the solution is an ever-updating and fully synchronized “command center” for everything across every app you may be using.

I agree we need to attack this problem, but is another proprietary service to connect via proprietary APIs to your other proprietary services really the best answer? This looks like even more complexity than before (when something breaks, who do I go to for help?), except now I'm paying yet someone else to stand between me and my data.

We didn't get where we are today, in any field, using this approach. We don't have 30 different measurement systems, and a company whose job it is to coordinate conversions between them. We don't have 30 different text file encodings (any more!), and a company whose job it is to automatically convert them as necessary. We say: here's the standard, and now you can use it or be ostracized in the market.

If writing custom adapters to interface with GitHub/GitLab/Jira/... is anything other than a temporary solution, while you work on some grand plan to get issue-trackers all on the same page, then it's just a money-grab on the road to failure. Someone will cut off API access, or drive up your costs, or refuse to offer an API, and users will be stuck with "one command center (for the 3 most popular services they use), plus 3 oddballs", and it's just not going to be worth the hassle.

It's a band-aid. Normally you stick a band-aid on something that will heal itself, and then rip it off tomorrow. This particular problem is getting worse. This is a very pretty band-aid, but you've applied it to a sucking chest wound.

I think instead of another tool to wrangle too many tools is as you already headed off: email.

Gmail already reminds me of stuff like emails I didn't respond to. I've set up some filters and scripts to do more like create a triage queue for PRs and such.

Email does indeed catch and notify you of most things, and Gmail is getting smarter every day. The one major downfall, though, is that it's stale: the minute you receive an email it's out of date, and if anything requires additional emails to send updates.

It's also those "filters and scripts" you've set up to create your own triage queue that we're trying to replace. The average user should not have to write scripts to receive and process their work in an efficient manner. That's what we're trying to solve at Monolist!

This conversation reminds me of the ever-relevant xkcd: https://xkcd.com/927/

That looks really cool, but unless employers are paying $10pcm seems steep to me, considering it's more than the underlying tools (which are potentially all used at free tier).

Have you considered pricing by #integrations connected?

We're always considering various pricing models, and per-integration was one of them. For the time being, though, we've decided that would be counter to our primary goal: allowing you to see and process all of your work from in Monolist, as quickly and easily as possible.

Hm, I do get that, but I would suggest that the value changes with the size of my 'all'.

To be honest, just based on the screenshot it seems like a nicer management for even a single service than GitLab/GitHub's notifications.

Liked what you folks are doing with monolist. :)

Yes, the problem is that all of these are not just programs but filesystems/databases. Nobody can be compatible with anybody else, except by drinking through the straw of an API, when you're allowed to. That means we're never going to settle on even bad ad-hoc standards like XLS.

The only standard that’s going to survive, I think, is email.

Anything accepts email - almost anything can send email. So for example in Aether Pro we’re building email pipelines so you can tie your CI to a ‘subreddit’ and all messages coming from that CI would appear under, without polluting everyone’s inboxes. It can also trigger further actions based on parsing those emails as well. It’s messy, but it’s the only thing that kind of works with anything.

We’d love to be able to rely on APIs of other tools, but those are just never there, or too fragile, or the API owners think the data they are ‘leaking’ is too valuable to let go, so email it is.

Funny you mention this. My friend runs a jewelry business and one of the things he needed to do was move something from Etsy to asana. There was no API so we used Zapier’s email parser to parse the order emails to send into Asana. Works pretty well.

https://parser.zapier.com/

That's interesting! Any yes, that's what we're going for, but in a way that also allows you to see the messages too, not just use as triggers. So you could bind your `support@` email to it and answer with humans as well.

It's all in the context of providing an internal gathering space that isn't just a notification-heavy Slack channel. Reddit-style forums work surprisingly well for both humans and robots, so it's pretty nice.

On the contrary, with so many tools have built in integrations now, my theory is that data is more easily integrated than ever before.

Obviously the missing startup idea here is the company that integrates you with everyone as a service

This is just a consequence of a free market. A communist would worry that letting people organize themselves to grow and sell food would end up with a Cambrian explosion of small businesses, each vying with each other for dominance. If they will follow the same model as everything else, we'll end up with monoliths in control of everything, just badly joined together.