What's with the hagiography? Culver made things people came to depend on, then those things disappeared.
I don't see how this is any different than picking up women and telling them you think they're serious girlfriend material in a context (business services) where that's the expected standard, then dropping them for the new hot thing.
Why is it suddenly acceptable to do this just because they called themselves a startup?
You're making statements which depend on information you don't have. How do you know grove.io was dropped for the new hot thing? Perhaps they weren't making money. Perhaps they were being destroyed by the two larger startups in the space?
Why do you assume the worst of this company? The rest of your statements in this thread are really aggressive, and rely on very negative assumptions, which do not seem to have a basis in fact.
>How do you know grove.io was dropped for the new hot thing?
Because that's what happened to her last six projects?
Are you completely incapable of inductive reasoning or are you being obtuse so that you can make the total unaccountability of SV founders a moral crusade?
Wow, that escalated quickly. Try to remember that you're talking to and about other people. Jumping to the worst possible assumption about other people is not a kind thing to do, but it's all I've seen you do in this thread. As a result, I'm out.
>Revenues that had peaked at around $3.2 billion in 1983,[1] fell to around $100 million by 1985 (a drop of almost 97 percent).
It would be extremely unwise to believe the startup industry couldn't be subject to the same problem. VCs are getting uncomfortable with the valuations, the constant buyouts and abandonment are burning out consumers.
Were I not working on a startup of my own, I'd be happy to take upon somebody's profitable but small red-headed stepchild business.
These things are not really on the same level. Google usually gives more than a years notice, and always has a way to export your data. These guys are shutting down in the month and it looks like the only help you get with your data is a link to a gist on github.
The Google API I was using had a 6 month lead time, no recommendations for graceful transition, no offer of data dumps, and the final shutdown date was never communicated.
The API I was using, was shutdown without any communication. (Adsense for ajax - announced at Google I/O 2010). They simply closed my account without paying the money I was owed (substancial sum). I later found out from a Gooler "yeah they decided to shutdown the product".
Beware of relying on anyone, even a big company who says they won't be evil.
I am in the middle of moving an API over from a Google one that got shutdown recently. This has cost me a substantial chunk of time, more than it likely has cost you.
I'm viscerally aware of inverterate corporate capacity for volatility.
No NO.. it's not because they're small. It's because tech start-ups have a history of shutting down or selling, and leaving their users in the dust.
The list is long. Another recent example was Sparrow. I broke my rule about buying/licensing software from small companies (unless I got the source) with Sparrow. I didn't just buy 1 copy, I (we) brought 15 (for the office). And of course, I got burned. Again.
It will not happen again. Period. Unless you tell me up front your plans - what you plan to do for me, the user, when/if you fail or sell.
It is not only tech start-ups that do that. Big tech companies regularly kill or sell off divisions or product lines. Most times, a start-up might still be on its first product line, which makes you think selling off their single product line or single division in this instance the whole company to be different from what the tech giants do when they sell or kill off product lines or divisons.
Start-ups with more than one product line, sometimes sell off one product and keep the rest acting thesame way big companies do. So, Yext a start-up sold their Felix product line to IAC eg:
I have shown above, an example of start-ups and giants selling a product line. You can Google around for example of tech giants and start-ups with more than one product, killing off a product line.
Did you really get burned with Sparrow though? You bought software, not a service. Them being bought, and shut down, by Google has zero effect on you given that you can continue to use their software. Forever.
According to a friend, the most recent version of Sparrow is essentially broken (100% CPU and crashes). I haven't upgraded in a while for this reason, and I'm not expecting that issue to be fixed, ever.
That said, I'm still using Sparrow on my laptop and desktop machines as well as my iPhone. But probably not for a whole lot longer.
I don't know about your friend, but I'm happily using the latest version of Sparrow with no issues whatsoever, maybe he has some other unrelated problems...
Well yes, but doesn't it's usefulness come from the tight integration with gmail only features? disclaimer; i only used Sparrow for a bit a long time ago so perhaps they've made these features work in regular IMAP as well..
I don't know exactly the protocols behind Exchange (IMAP ? MAPI ?), but it seems to me that it is, for now, Google's prefered way of accessing emails & calendars from a mobile device (at least from iOS).
You paid $150 for software which still works, which had no promise of updates forever anyway, and you're upset?
Not that your point is invalid talking about Grove - suddenly everyone who used it has to move in under a month. But I don't get the upset over Sparrow. If it helped you at the time, it should help you now.
I don't want to rehash Sparrow. But, if they'd had fixed long standing bugs, and added the features they promised I would not be so upset about it. But they didn't. They dropped the project and went on to Google.
Leaving with with a ridiculous "feel-good" blog post.
My point though, this isn't uncommon. And this kind of user treatment is one of the big reasons many tech start-ups have a tough time making the sale.
Now of course, if said company manages to get momentum (like a Dropbox, Github, FB - to name a few) - I guess they are no longer startups.
You overcome it by offering something valuable for users that they can't easily setup themselves.
As far as I can see, Grove.io didn't do this. They didn't have any easy means to grow quickly.
Also perhaps they're paying a lot for hosting (At rackspace). I don't know, but there's no reason they shouldn't be making some profit if they have a few paying customers. Shame they can't build on that.
You overcome it by offering something valuable for users that they can't easily setup themselves.
Why can't traditional IRC services be used for this? I'll preemptively counter the end-user configuration side of this by saying it's increasingly easier in a managed workstation environment to deploy images with software required for that worker's tasks preconfigured. Even in a non-managed environment, an IT staff willing to build the packages and make the configuration edits can make accessible an installation candidate stored for access in an infrastructure library so users can save (after proper credentialing and auth checks have been satisfied), install and login.
Security, perhaps? That's always a valid concern to have, but if that's the case I would hope that an adequately planned and designed audit of any service not being managed internally gets the same look. Corollary: perhaps one should not be using anything not managed internally for sensitive matters to begin with; collaboration and non-secure communication where a failure of this system wont halt production or cause the company to incur significant loss however are par.
If I'm off base here, I'm willing to discuss it further. While I loved IT, I had to run for the door after getting burned on multiple opportunities to manage programs and create user friendly but secure policies. And by burned I mean hired to do exactly that, only to end up in hyper-glorified purchasing support roles. shudders
It takes time. Some kind of competitive advantage over everything else in the marketplace will help to. People need a reason to bet on your company which overcomes the risk in instability.
As time passes and your service stays solid more people will come on board. Something like github is a good example. I doubt many big companies would have considered relying on them early on, but their track record has changed that now.
Yeah but, Github is a different sort of product. You don't lose much if it shuts down (assuming you have your code). You can push your code someplace else.
I disagree, maybe that might have been a point that allowed more people to give it a try in the early days. A lot of companies have integrated APIs and built workflows around the github specific way of doing things.
I really meant my point to be a counter to its parent.
But since we're on the topic, presenting social proof is also pretty useful. Show customers that people know, show the press that featured you, show them who you are, who your advisors/investors are, show them whose tweeted about you.
(Maybe writing this will be a catalyst to take my own advice for CircleCi)
But that's hacking trust. It's opposite to just being honest and having a publicized contingency plan, or open-source code.
edit (since I can't reply): logic being that social proof is good for business, but has no substance. It doesn't make it any better for users when it comes to shutting down.
The substance of social proof is that it shows that a lot of people have faith in your product and trust you enough to pay you to use it. It's not just a gimmick, it's a concrete psychological trigger.
Yes, of course social proof has substance as marketing strategy. But gaining trust is orthogonal to actually being reliable. (this is still about the top comment)
I disagree about trust and reliability being orthogonal. Unreliable products burn their bridges rapidly. Social proof can take many forms, from raw total user numbers to user testimonials. You're not going to collect testimonials if you have a shitty product.
>I really meant my point to be a counter to its parent.
I don't believe I've ever seen you do anything else on HN. I know you to be a reliable person, no reason to think you'd suddenly get fickle and take something I said seriously.
Do you mean to tell me that if somebody rolled up with a check written out for your price you wouldn't light the servers on fire and run for the hills? Realistically the only people who are cared after in any acquisition are the investors so that no bad-blood is in the water for the next acqui-hire. Customers are always left in the dark.
If you want any credibility to the contrary, you'd better start presenting your customers with an SLA that guarantees a detailed transition with a timeline in the case of company failure/acquisition.
Or you can just play PR games. Whatever bare minimum your sense of honesty necessitates.
I'd rather just sit on a happy customer base, but I never thought I'd become a millionaire anyway.
> check written out for your price you wouldn't light the servers on fire
> I'd rather just sit on a happy customer base
So everyone else is just in it for the money, but not you? If you can believe it about yourself, perhaps you'd be willing to extend some of that credulity to others?
There are always early adopters that are passionate about every new product they can find, and there are also skeptical customers that refuse to use anything provided by startups. That's actually how sustainable startups grow.
Why should anyone create software just so you can have it for free? You're not entitled to open source software, or the goodwill of others. If they decided that they didn't want to continue running their product, they can choose to shut it down.
This is exactly the same as Sparrow, TextMate, etc. None of these companies owe you anything to where they should be required, or even expected, to open source their work.
I don't demand anything of them, but they won't create a dependency where I previously had none and expect to be rewarded with money for it.
I am making founders aware of this attitude so that they can
1. Realize that there's a problem
2. Distinguish themselves among their competitors by addressing this concern
I'm not aiming to prescribe solutions, just describing the heuristics I presently rely on to determine if a service is likely to become a liability. I always do a fluid cost-benefit analysis beyond the black-and-white I described in my top comment.
That you believed what I said had anything to do with "demanding" free labor of anyone is telling and indicates a defensive posture on the subject.
Not a surprising reaction to have, given that Sentry (your errors-as-a-service project) depends on people trusting you not to just shut it down tomorrow.
Sentry is also open source, but for very different reasons than what you describe. I treat it like part of the business value, but that also means that many people can simply run their own, which means potential value lost (I wouldnt argue that there is value lost, but its not something that can be ignored).
>Sentry is also open source, but for very different reasons than what you describe. I treat it like part of the business value, but that also means that many people can simply run their own
Then there's no issue in the hypothetical scenario I laid out.
I'm a Sentry user (of the hosted service) because it's open sourced. I wouldn't have given you a seconds notice otherwise and I doubt I'm alone in that.
Why be so defensive when you're clearly not in a position to be guilty of leaving all your customers up the creek?
One would want to use an external service, because... well... it's a service. You are paying for someone else to maintain the system and care about the uptime, scalability, security, etc. You surely do not imply that you would pay grove.io simply because you can't bring your own IRC server up, do you?
If you're a small startup, putting forward a statement that all the code will be open sourced if you shut down should increase the level of comfort your customers have in the product.
What are the downsides I'm not thinking of? Companies that reuse code across multiple products, perhaps. Product A dies, but uses component Foo in Product B that still exists, and represents some kind of special-value-add.
The most obvious downside is that it creates perverse incentives -- potential customers benefit if you fail. It also telegraphs a lack of...I don't know what the word is. Tenacity? It's kind of like putting a bounty on your own head so that at least somebody can benefit if you die. You really want people to be invested in your survival.
It also limits what you can do with your program. If your program uses code you don't have a license to release, you can't open-source it.
It's debatable customers benefit if a company fails and open sources their product. The customer, assuming they're willing and able to install it, misses out on any further upgrades (rare is the salvaged open source that goes anywhere) and support. Though I don't discount that there is _some_ benefit and that many customers might over-estimate that benefit.
I thought about this earlier - putting a statement on circleci.com saying that if we shut up shop then we'll open source everything. However, I think its dangerous to plant that seed in a users' mind - I think it suggests that there's a danger of that happening (which there isn't, CI fans).
I actually think the solution is to ignore customers with this view. We'll get their business when we "cross the chasm".
It gets tricky if your exit path ends up being the sort of combination talent/product acquisition where your new employer wants to keep your tech proprietary (see: Apple acquiring Siri, Facebook buying Face.com and shutting down their public API).
Ken's mind just works in a different way to most people. You explain your problem to him and he'll respond with some question or statement that turns your entire perspective inside out.
"The aggressive use of a small number of abstractions is, I think, the direct result of a very small number of people who interact closely during the implementation."
And I agree completely. Varnish is goddamn magical and a fascinating exercise in a principled approach to kernel-oriented memory management (a mindset I don't normally undertake).
All I'm really aware of are Google Proprietary Magic™ (motherfuckers. I want colossus baaaaad), CFS from DataStax, Storm (sorta-not-really?), and Spark.
Sector/Sphere is what the Sloan Digital Sky Survey uses.
Instead of supplying map and reduce routines, you implement generic "user defined functions". This gives you some more flexibility about how the work is handled, though if you want to just implement map and reduce UDFs, it supposedly gets better performance than Hadoop.
It's also designed to support distributing work over WANs. I think Hadoop really wants every compute node to be on the same LAN.
>I think Hadoop really wants every compute node to be on the same LAN.
Fucking a-right it does. You should see the labyrinthine depths people descend to in order to scale Hadoop. Sub-clusters of sub-clusters, rack-local clusters, Zookeeper nodes all over the place.
You should write a page for it. You aren't supposed to create pages for your own projects/products on wikipedia; they should come from neutral parties.
Those that don't give a fuck are using Campfire/HipChat.
Those that do give a fuck are usually hosting their own IRC.
Find a way to squeeze out both and you have a potentially nice business model. (Hosted IRC + nice web clients for paying customers?)