9 ms·

Startup dilemma pre-acquisition: "they're just a startup! how will I know they'll be around in 12 months?! so risky!" Startup dilemma post-acquisition: "they'r

by johns 12y ago

Startup dilemma pre-acquisition: "they're just a startup! how will I know they'll be around in 12 months?! so risky!" Startup dilemma post-acquisition: "they're no longer in control! how can I trust they'll be around in 12 months!? so risky!"

skrebbel 12y ago
Good point. As a startup owner myself, I somehow feel more comfortable depending on startups than on BigCo's (hence the rant), but maybe you're right that that's more emotional than rational.
jgable 12y ago
Solution: "They're a stable, growing business that is profitable and intends to be in business for themselves for a long time! Not as risky!" Not under the control of the customer, obviously.
georgemcbay 12y ago
Being acquired by Google almost solves the dilemma in that statistically you can be nearly certain that whatever product or service a newly acquired company provides will be a dead project within 2 years. I know that the acquirees are saying otherwise in this case (and Google is surely saying the same to them), and they might be right this time, but "nothing will change" is virtually always the line, until it suddenly isn't. FWIW, I'm not even knocking Google (or Firebase) for this state of affairs; just noting that anyone paying attention will have seen this play out dozens of times in a way that is unpleasant in the medium to long term for anyone relying on the acquired company's technology.
ggreer 12y ago
The solution I've come up with is a pledge to release the source code if the product dies.[1] We've done this at Floobits, and it makes our users' lives less stressful.[2] 1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunset-pledge/ http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse... 2. https://floobits.com/pledge https://floobits.com/pledge
- baddox 12y ago
  What good is a pledge? Once the product dies, there's presumably little incentive to abide by it.
  - ggreer 12y ago
    Little incentive? Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. The internet has a long memory, and people would not trust you in the future.
    - baddox 12y ago
      > Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. But that's just the same incentive for a company to continue providing the same level of service after being acquired.
    - sliverstorm 12y ago
      How about the pain-in-the-butt that is organizing, packaging, and releasing an organic network & development environment when you have other bigger things on your plate? I'm sure there are a few companies here and there with everything already nicely packaged. Yet, most places I've worked, it would be a herculean effort to pull the tangled jungle that is the internal network & development environment into one halfway-functional package. It's less than ideal, but it is usually extremely low on the list of priorities as well as virtually untestable, unless the business model involves a large number of functionally identical VLAN's. Also, names of people are usually not very strongly attached to products.
      - seanflyon 12y ago
        Who said anything about organizing or packaging? Just put the code up on Github with a reasonable license and walk away. Running and maintaining is of course still a problem, but you can hardly expect a company that is out of business to do that.
polarix 12y ago
https://sandstorm.io/ https://sandstorm.io/
christiansmith 12y ago
I'd like to take that devil by the horns and strongly suggest that companies like Firebase, who clearly deliver a critical infrastructure dependency for anyone using their service, should open source their platform as an act of good faith toward their customers. No one wants to run yet another cluster, but anyone with an eye to business continuity ought to want the assurance that they can migrate to and from their own servers if that need should arise. That might not be in the short term interests of Firebase, but it's definitely in the long term interests of their customers. Why would anyone ever base the future of their own business on the exit needs of another company's investors? It is a ridiculous risk. As much as I love what Firebase has built, I'd never use it for anything more than a toy project for that exact reason. Basho, ElasticSearch and Docker(?) seem to be on a good path with commercial open source models. Is there any reason that a startup like Firebase couldn't do both? Offer their open source product as a service with non-critical value adds? GitHub is another example that comes to mind. If they were to get bought and shut down, it would be a pain in the ass to set up new remotes, but no one would have to stop using git.
- Nevraeka 12y ago
  +1 to open source the platform
  - dude3 12y ago
    Node.js + Socket.io + Bootstrap + AngularJS + Angular Socket.io + 1000 lines of code
    - matthewmacleod 12y ago
      But that's a thousand lines of code I don't have to write. And integrations I don't have to do. And libraries for lots of platforms. I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase. Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.

by johns 12y ago

skrebbel 12y ago

Good point. As a startup owner myself, I somehow feel more comfortable depending on startups than on BigCo's (hence the rant), but maybe you're right that that's more emotional than rational.

jgable 12y ago

Solution: "They're a stable, growing business that is profitable and intends to be in business for themselves for a long time! Not as risky!" Not under the control of the customer, obviously.

georgemcbay 12y ago

Being acquired by Google almost solves the dilemma in that statistically you can be nearly certain that whatever product or service a newly acquired company provides will be a dead project within 2 years. I know that the acquirees are saying otherwise in this case (and Google is surely saying the same to them), and they might be right this time, but "nothing will change" is virtually always the line, until it suddenly isn't. FWIW, I'm not even knocking Google (or Firebase) for this state of affairs; just noting that anyone paying attention will have seen this play out dozens of times in a way that is unpleasant in the medium to long term for anyone relying on the acquired company's technology.

ggreer 12y ago

The solution I've come up with is a pledge to release the source code if the product dies.[1] We've done this at Floobits, and it makes our users' lives less stressful.[2] 1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunset-pledge/ http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse... 2. https://floobits.com/pledge https://floobits.com/pledge

baddox 12y ago
What good is a pledge? Once the product dies, there's presumably little incentive to abide by it.
- ggreer 12y ago
  Little incentive? Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. The internet has a long memory, and people would not trust you in the future.
  - baddox 12y ago
    > Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. But that's just the same incentive for a company to continue providing the same level of service after being acquired.
  - sliverstorm 12y ago
    How about the pain-in-the-butt that is organizing, packaging, and releasing an organic network & development environment when you have other bigger things on your plate? I'm sure there are a few companies here and there with everything already nicely packaged. Yet, most places I've worked, it would be a herculean effort to pull the tangled jungle that is the internal network & development environment into one halfway-functional package. It's less than ideal, but it is usually extremely low on the list of priorities as well as virtually untestable, unless the business model involves a large number of functionally identical VLAN's. Also, names of people are usually not very strongly attached to products.
    - seanflyon 12y ago
      Who said anything about organizing or packaging? Just put the code up on Github with a reasonable license and walk away. Running and maintaining is of course still a problem, but you can hardly expect a company that is out of business to do that.

polarix 12y ago

https://sandstorm.io/ https://sandstorm.io/

christiansmith 12y ago

I'd like to take that devil by the horns and strongly suggest that companies like Firebase, who clearly deliver a critical infrastructure dependency for anyone using their service, should open source their platform as an act of good faith toward their customers. No one wants to run yet another cluster, but anyone with an eye to business continuity ought to want the assurance that they can migrate to and from their own servers if that need should arise. That might not be in the short term interests of Firebase, but it's definitely in the long term interests of their customers. Why would anyone ever base the future of their own business on the exit needs of another company's investors? It is a ridiculous risk. As much as I love what Firebase has built, I'd never use it for anything more than a toy project for that exact reason. Basho, ElasticSearch and Docker(?) seem to be on a good path with commercial open source models. Is there any reason that a startup like Firebase couldn't do both? Offer their open source product as a service with non-critical value adds? GitHub is another example that comes to mind. If they were to get bought and shut down, it would be a pain in the ass to set up new remotes, but no one would have to stop using git.

Nevraeka 12y ago
+1 to open source the platform
- dude3 12y ago
  Node.js + Socket.io + Bootstrap + AngularJS + Angular Socket.io + 1000 lines of code
  - matthewmacleod 12y ago
    But that's a thousand lines of code I don't have to write. And integrations I don't have to do. And libraries for lots of platforms. I think you're undersstimating the added value – the point is that people don't have to bother setting up and maintaining all of those moving parts with a service like firebase. Case in point, I was building a small real-time web serice this weekend; it's exactly the sort of thing that Firebase would be great for. But given that I couldn't run it locally, and that there's no migration path if they were to acquired and shut down, I had to implement a half-assed solution on my own. If Firebase had been open-source, I'd almost certainly have ended up forking over cash for them to host it anyway.