Basecamp neglected integration partners by not providing an API for Basecamp v3

Basecamp neglected integration partners by not providing an API for Basecamp v3(github.com)

28 points by jamesfzhang 10 years ago | 9 comments

jamesfzhang 10 years ago |

TLDR:

- Basecamp releases v3

- Basecamp markets to their customers to upgrade to v3

- Some people upgraded & noticed their integrations with 3rd party applications no longer work (presumably thinking it's the 3rd party developers' fault)

- 3rd party developers aren't happy that they can't update their integrations since v3 lacks an API

- DHH says the API is in the works but hasn't been as high priority compared to other features on their list

- 3rd party developers get mad at DHH's response

hitekker 10 years ago | |

I think it may be worth noting that Basecamp 3 has been out for 3 months already and Basecamp has not clearly noted the timeline for an API's release.

Additionally, this comment does not inspire confidence:

>We have some 12 developers who have to manage every single version of Basecamp and other legacy products, as well as all new development on Basecamp 3.

dantiberian 10 years ago |

Example #18301 of why you should avoid building a business on somebody else's product. There is always a tradeoff between the risk of building on a platform, and the rewards for serving their customers.

Building for Android and iOS are partway down that scale, and it seems like Basecamp is right at the end.

> So priorities have to be made. We have lots of work left to do on Basecamp 3. Lots. The API is one of them.

Basecamp have shown and admitted that an API and their API partners are not a high priority for them (or it would have been done already, that's what a priority is). If I had built a business on Basecamp, I would be looking for other platforms to integrate with, or different products to build.

iambateman 10 years ago |

The surprising thing about this, to me, is that an API wasn't considered a core feature in the first place. The name "Basecamp" is meaningful only insofar as there are "trails" available into and out of "camp."

carlivar 10 years ago | |

Especially since one of the things that I first found interesting about Rails is how easy it was to write your API right alongside your UI code. format.xml and format.json and all that.

hitekker 10 years ago |

A little off topic: my colleagues have been using BaseCamp 3 and they are quite unhappy with it: especially since they're happy using Slack, Asana, etc. The UI and UX feel like a huge step back from BaseCamp 2, and I would say the tip of that iceberg is their logo.

You have a decent, perhaps not extremely iconic logo[1]. Then you slap something on top of it which looks trendy[2] but doesn't actually do much to solve the original problem and doesn't feel as good your previous design.

Does anyone else share the sentiment that Basecamp 3 isn't what were hoping it would be? I haven't discussed it much outside of my company so this may just be us not using it right.

[1]https://help.basecamp.com/images/logo-bc.png

[2] https://lh3.googleusercontent.com/ajz19_YsLqkPIJNuTcwNCe245X...

influxed 10 years ago | |

I haven't used Basecamp 3 yet. But criticism of a very minor logo update to bolster claims for user unhappiness seems like the wrong place to start.

If there's something about the new Basecamp you're unhappy with, a better place to start would be how it's regressed in accomplishing tasks or improving communication. Bikeshedding is a distraction.

hitekker 10 years ago | | |

Any alteration to the most visible and important element of your marketing/company/product is not a minor change, I would say.

In my mind and my collegue's mind, the mistake they made with the logo is a hint, or rather the start, of the underlying design problems with Basecamp v3.

cyanbane 10 years ago |

I am going to be in the minority here but I think that even in this day and age (2016) it is ok to produce a product which has a majority of it's value derived from a 3rd party API. In doing so though I think that you need to come to the terms that you are unable to reliably forecast for anymore than 24 hours ahead in time. The API access that you depend on can be Twittered out of existence (i.e. firehose). It could be Parsed out of existence (graceful exit from market) . Or it could be Basecamped (delayed?) into existence at some point in the future. I think DHH & Co. are legitimately going to release this but it just isn't high on the priority list for them. I don't think you can fault them for having their own list of internal priorities that may or may not involve helping 3rd parties at the speed at which those 3rd parties require.