Page MenuHomePhabricator

On Third-Party Integrations
Open, LowPublic

Assigned To
None
Authored By
epriestley
Dec 28 2018, 9:57 PM
Referenced Files
None
Tokens
"Yellow Medal" token, awarded by avivey."Like" token, awarded by 20after4."Piece of Eight" token, awarded by cburroughs."Mountain of Wealth" token, awarded by jcox.

Description

We are sometimes asked to provide third-party integrations. The cost to build and maintain these features is often much larger than the cost to build and maintain similar first-party features, and it often feels like burdens and benefits are not being shared fairly between us and third-parties.

In some cases, it feels like we're building features or integrations purely because we're more agile, even in cases where the third-party is a paid service owned by a company a thousand times larger than us. An ancient example is T11937, where a user asks us to build a workaround for GCE support for sql_mode instead of asking Google to support sql_mode. This user was a Google customer but not a Phacility customer. This kind of request does not serve our interests.

Broadly, our long-term strategy is to destroy the entire market by commoditizing every tool so we're the only company efficient enough to be left standing, not to be a hub of really well-engineered free glue connecting a lot of paid services with large sales teams. For example, I'd rather be putting effort into improving Harbormaster and eroding the market for services like Buildkite and CircelCI than building integrations with these tools.

To better balance these concerns, I'd like to move toward a model where more of the third-party integrations we build and maintain (particularly for paid services) are licensed rather than free. I think this generally aligns incentives better: third-parties are incentivized to build and maintain the integrations themselves, customers are incentivized to move away from paid third-party services to free first-party services, and we're directly incentivized to maintain these integrations as long as they're being used. The only sort of perverse incentive here is that we're sort of incentivized to become paid glue for a bunch of third-party services, but I think so many other factors push us away from this that it's not much of a risk.

In particular, T13222 anticipates developing a Duo integration. Duo is a ~$6/user/month paid service owned by Cisco (which had revenues of $50B in 2018) with a "Contact Sales" button on the homepage. Duo is also currently probably the best option in this space given the U2F state of affairs (see T8787) and we can not reasonably replace it today without native iOS/Android apps to read U2F keys with NFC and receive push notifications, but when browser support for U2F improves and we have native apps I'd like there to be good financial incentives to replace Duo with first-party equivalents. Thus, I'm planning not to bring Duo support into the upstream core, and provide it as a licensed extension in the future instead.

This generally depends on T5055.

Event Timeline

epriestley created this task.