
Basecamp neglected integration partners by not providing an API for Basecamp v3 - jamesfzhang
https://github.com/basecamp/bcx-api/issues/196
======
jamesfzhang
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
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
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
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
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
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](https://help.basecamp.com/images/logo-bc.png)

[2]
[https://lh3.googleusercontent.com/ajz19_YsLqkPIJNuTcwNCe245X...](https://lh3.googleusercontent.com/ajz19_YsLqkPIJNuTcwNCe245XE6hx9Q7SFSsqqfDUU0Gqaxia5rFFmh9CZ_4Fqf934=w300)

~~~
influxed
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
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
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.

