Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I might not be fully understanding your point but I would disagree with the idea that just because many companies have tried to integrate tools together and failed that it must point to some inherent flaw in the idea itself. Instead it should just point to inherent difficulties in executing the idea.

All of our tools having silos of data and only having difficult to implement one-to-one integrations seems broken- it does not feel like it has to be this way as part of the nature of the software.

Here are two reasons we have not yet seen this executed well:

1) If you're Atlassian or Microsoft it's likely perceived that it's not in the best interest of your business model to spend a non-trivial amount of resources on deep integrations with 100's of popular 3rd-party apps but instead it's much easier to see how it is in their best interest to just clone those popular apps and deeply integrate them into your suite. This way they keep users using their software and are able to charge for the new app (or eventually charge more for the suite).

2) So then there's space left for a software solution to enter the market that does world-class deep integrations with the 100's of popular SaaS api's and a great UI/UX that makes working across all of these apps intuitive- potentially an entirely new level of usability in modern productivity workflows. But as a startup idea this actually does tend to fail and I think it's primarily because it's a non-trivial engineering problem to build these integrations and a startup, with scarce engineering resources, is forced to choose ~1-3 integrations to start with as their initial customer-facing version. This then results in a product that is not compelling and just seems like yet another one-to-one integration solution.

It seems that if a new level of software interoperability enabling a new level of user experience is to happen the startup would have to be very well funded with a decent "stealth mode" runway. Or a large software company would have to throw a decent chunk of resources at the idea (not PM's convincing the business case for an integration piecemeal).

And then there's one other way this could happen:

If you look at Android and iOS you see that they already have thousands of productivity apps integrating deeply with their native API's. And already this has enabled things like iOS Actions Extension API where you can send something like a pdf to any app you have installed that registers its ability to handle pdf's. On Android features like Slices allow an app developer to put a "slice" of their UI into other apps based on the intent or action happening on the other app. I can see a future where Apple and Google increasingly push their mobile operating systems to the desktop-size screen and the productivity user base. While it may seem unlikely now it may be that iOS and Android are best positioned to introduce a new level of software interoperability to the modern enterprise productivity market in the form of a better desktop experience.



> All of our tools having silos of data and only having difficult to implement one-to-one integrations seems broken- it does not feel like it has to be this way as part of the nature of the software.

The problem is completely self-inflicted and caused by greed. It isn't difficult to make software interoperable - you actually have to work hard to make it non-interoperating. Which is precisely what aforementioned companies did by creating data siloses exporting just tightly-controlled APIs, guarded by ToSes preventing interop from happen organically. SaaS companies broke interoperability on purpose.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: