Hacker News Reader

Comment by alexcroox | Hacker News Reader

While I admire 37signals I do find myself increasingly comparing them to Google and their offering. They make incredible services, but it's hard to trust them to build your business workflow around their products. If there aren't stripping back critical business features such as time tracking for our billing in the new Basecamp, they are looking to shutdown or sell others a few years on.

I hate corporate software as much as the next guy, but at least you know it will be around and supported for a long time to come and without stripping features core to running your business. /rant

View on HN

The only feature I can think of that we ever removed (I might be wrong) is OpenID, because almost no-one used it and it was really confusing.

Time tracking is still there in Basecamp Classic, and that's not going away. If you rely on time tracking in Basecamp Classic you can continue to do so.

See this from the announcement page FAQ:

Q: What about Basecamp Classic? "We are fully committed to running Basecamp Classic forever." - http://37signals.com/

I get the feeling if a majority of people had switched to the new Basecamp, they would have killed off the old one, but it's such a breadwinner, they are not going to take it away, although I suspect if it ever gets to the point that a tiny portion is on Classic, they will change their mind, which is unsurprising as that's more or less been the concept of their company (to make bold statements and change them when circumstances change).

The number of people have nothing to do with it. We won't kill it off because we made a commitment not to. We're keeping our word. Simple as that.

I want to switch to new basecamp, been a basecamp classic customer since 2005 (do i get a gift basket?), but rely on time tracking for my business. I don't want to have to rely on an external time tracking tool.

I really don't understand how the author of the parent post is still angry about this. 37s did the responsible thing by continuing to fully support the old version, giving users time to migrate (or not migrate).

I think there are a lot of 3rd parties that integrate with the new Basecamp to provide time tracking. Harvest is the one that immediately comes to mind. While this might seem to not be as good as a first party experience, I would argue that it is better to use a real time tracking app like Harvest, which is waaaaay more capable than the time tracking in Basecamp Classic.

Whatever criticisms you might have of Basecamp, they are certainly focused on avoiding feature creep and bloat. I suspect they agree with my assessment that Harvest et al. provide a better time tracking experience, so there is no reason to complicate their product with a (poorer) duplication of their features.

Paymo time tracker also comes in mind :) (shameless plug)

A million times this. We had a small division of our company using Basecamp for a bit but it got canned after some changes and they went crawling back to Salesforce.

It stinks but it stinks consistently!

It's pretty well documented that Basecamp is for a certain type of business. There's no reason to bash it. It serves a purpose, just not the one your small division found useful.

I admire a company sticking to their values when they could easily throw them out the window and grow into a massive corporate machine.

Something as trivial as time tracking can easily be done with an external application[1] that plugs directly into Basecamp.

1.) https://www.toggl.com/

I think this is a problem that's inherent in "the modern web". Trusting part of your business process to a SaaS application is always going introduce risk. Sometimes it's a calculated risk, and if you have contingency plans in place then it's acceptable. But in most cases, users simply aren't prepared for the day that a critical part of their workflow changes or disappears.

I know it's not a popular opinion here, but using SaaS is no different from outsourcing part of your operations. If it's a small part and there are plenty of direct competitors, the risk is minimal. However, if it's a critical part of your system and there are no direct alternatives, you really are putting the safety of your business in the provider's hands.

Shhhh... 99.9% of the Y Combinators are SaaS.

>Trusting part of your business process to a SaaS application is always going introduce risk.

Trusting part of your business process to yourself is always going to introduce risk.

This is the primary fallacy of the anti-SaaS argument. Cloud providers go down, but so do you. For an in-house solution to be superior from a reliability perspective, you not only need to show that cloud providers go down, but that you go down less. Which, unless you are in the infrastructure business - or have a large and competent (read: expensive) business area that's in the infrastructure business - is not terribly likely.

I strongly disagree.

Like many others in the industry, I've had network applications which have run for years without unscheduled downtime. When I'm hosting my own application, I can architect whichever failover/redundancy solution I see fit. If my application does go down, I have physical access to the server and the data. My dependencies are all local, clearly outlined and easy to manage (from a risk perspective).

On the other hand, if I trust your SaaS application I'm also trusting that your backup and resilience procedures are at least as good as mine. I'm trusting that your dependencies are all managed in such a way that a failure can quickly be remedied or a contingency plan activated. I'm trusting your providers in the same way I'm trusting you. The opaque black box of your application frankly scares me. I can manage what I can see and what I can understand.

Not to over generalise, but there is a trend in SaaS application design towards the school of "let someone else worry about it" dependency management. This is clear in both infrastructure and libraries/frameworks. Many even outsource critical functionality to other third party SaaS services altogether (push notification, messaging, queue management, transcoding). Besides core application architecture, we also have to worry about connectivity (mine, yours, all of your dependencies). That's a lot of moving parts which can (and do) fail.

I trust my transparent, well documented system with its clear contingency plans much more than your opaque SaaS application, its unknown dependencies and its myriad moving parts.

And as we see all too often on HN, it's not just about downtime - SaaS applications shut down and disappear. If you're lucky, you get a chance to export your data. I'm certainly not suggesting that companies should continue to operate them at a loss for years, but given the choice between relying on someone else's SaaS product and depending on a locally hosted application, I'm going locally hosted every time when it concerns critical business workflow.

I'm not anti-SaaS at all, I just think we should be clear in our own minds about the risks introduced by relying heavily on third party providers (and I mirror that awareness in dependency management in my own software).

(On a side note: I find it interesting that while many of the users on HN ardently support SaaS, they condemn always-online DRM.)

Well, what would you have them do? Would it really be better for them to keep spreading themselves thin supporting too many products?

On the contrary, I think them refocusing on Basecamp should give you more trust that they won't pull a Google and pull the plug on it.

The problem is spreading yourself too thin in the first place, getting people to rely on your products, and then pulling them. I think it's much more acceptable for a small business like 37Signals to do this than a large one like Google. Google has the resources to keep products around, 37Signals doesn't.

Even if you have the resources to support something, should you if its not your core focus? Personal I feel that Google is still run as a startup, which is fantastic however people expect Google to be a corporate company.

How is google anything like a startup?

I meant startup as a culture not in the terms of funding. The fact that Google starts and closes down products very frequently is evidence of this. What about Google X? Isn't that a bit like a startup?

Maybe I meant to say that departments WITHIN Google are run like startups not Google itself.

>> "people expect Google to be a corporate company."

It is a corporate company. When millions of people rely on your products you need to be careful when introducing new ones and pulling old ones. I don't think you can run a business like a startup forever if you have millions/billions of users. You cans till maintain some aspects of that startup culture but there are other aspects you have to leave behind. You have to think of how anything you do is going to affect people's long term view of you. The Reader shut down may not have affected a majority of Google's customers but now some people are wary to adopt new Google services. If you pull that kind of thing often enough you damage your long term prospects.

Indeed, Google is a corporate company. I probably meant to say that certain departments have the culture of a startup.

My main point (and question) of my comment was in the first sentence.

Sure, it's inconvenient for the end user. But as someone who's started a few projects myself, I would hate to think that starting something means you vow to support it until the end of times no matter what happens.

I think the target market has a big influence here.

For end user software, it's not such a big deal to drop support.

But for a project like Basecamp, businesses are buying it and potentially investing a lot of time and money to integrate it into their processes. Companies buying that kind of software expect it to be around a while. It's a bit disingenuous to sell to them knowing it may not be supported after a short time.

Reply on news.ycombinator.com