Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ship.io says goodbye

ship.io

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Ship.io says goodbye

#21

Post by cognivore »

nathancahill wrote: post #12

I'm curious about the shuttering timelines that failed startups use. Three weeks is awfully fast to go from operational to shutdown for a service that customers rely on. I see two options, either could be reasons that a startup would fail: 1. Customers don't rely on the service. 2. There are no customers. Otherwise, why not leave the servers on for another month? EDIT: 3. The service isn't automated enough to be run…

I keep hearing "fail fast" as part of the start-up rah-rah. They just took it to heart.

Re: Ship.io says goodbye

#22

Post by nathancahill »

chrissnell wrote: post #17
nathancahill wrote: post #12

I'm curious about the shuttering timelines that failed startups use. Three weeks is awfully fast to go from operational to shutdown for a service that customers rely on. I see two options, either could be reasons that a startup would fail: 1. Customers don't rely on the service. 2. There are no customers. Otherwise, why not leave the servers on for another month? EDIT: 3. The service isn't automated enough to be run…

If your priority is returning the remaining investors' money to the investors, why would you keep the lights on?

I'm wondering specifically about keeping the servers on. Server costs are much less than the cost of "keeping the lights on".

Re: Ship.io says goodbye

#23

Post by pbiggar »

[Disclaimer: I'm founder of a competitor (https://circleci.com, which offers CI/CD for iOS and Android as well as web apps, open source, etc).]

I don't know why it shut down, but my guess: customers didn't want to use one CI system for their iOS builds and another for their server-side builds. This was one factor in CircleCI acquiring distiller.io (which was a ship.io competitor) last year.

The history here is very interesting:

The original ship.io product was built by CISimple, and the assets were sold to Electric Cloud after CISimple shut down in 2013.

Electric Cloud is a ~13 year old VC-backed startup that sells a C/C++ build distribution service (think distcc, but much faster and better). (Interesting side-note: EC was founded by prolific HN contributor jgrahamc, and by John Ousterhout, who created TCL and coined the term "scripting language".)

EC's customers are mostly very big embedded systems makers, so it's a very enterprisy market. This market was good but AIUI their revenue growth flattened out sometime after hitting $10m/yr in revenue many years ago

A few years ago EC branched out into the Continuous Delivery space to rekindle that growth. Their continuous delivery products are AFAIK being sold in the same enterprisy top-down fashion as EC, as opposed to the bottom-up developery approach that CircleCI, GitHub, New Relic, Heroku, etc, use.

Ship.io was, I think, the first of EC's products to be sold bottom-up, and that was aimed directly at developers. I believe this is the best way to sell into this market, so it seems ship.io was going in the right direction. In fact, I believe it even operated somewhat autonomously from Electric Cloud, with a separate team based in SF instead of Silicon Valley.

I would guess they shut down because they didn't get product market fit (which would be true if their customers wanted server-side CI in the same product). But it's also possible (pure conjecture here) that the bottom-up autonomous feel of ship.io didn't gel with the top-down enterprisy culture of the mothership.

Re: Ship.io says goodbye

#24

Post by zacwest »

pbiggar wrote: post #23

[Disclaimer: I'm founder of a competitor ( https://circleci.com , which offers CI/CD for iOS and Android as well as web apps, open source, etc).] I don't know why it shut down, but my guess: customers didn't want to use one CI system for their iOS builds and another for their server-side builds. This was one factor in CircleCI acquiring distiller.io (which was a ship.io competitor) last year. The history here is very…

I use CircleCI for iOS CI/CD and one of the biggest reasons is it doesn't try to be an all-encompassing solution for what I need: it executes tests and reports results.

I wanted it to do more, so I wrote some simple tooling to do more. I wrote up in a blog post for ease of reproduction: http://zacwe.st/blog/automating-ios-builds/

I think for most users, just running the tests is a step in the right direction. Handling distribution (the CD part) is something you grow into if you haven't seen it before. If I have to think about how to configure every aspect, I'm probably not going to get very far into the setup.

Re: Ship.io says goodbye

#25

Post by javajosh »

nathancahill wrote: post #22
chrissnell wrote: post #17

Earlier quoted context omitted.

If your priority is returning the remaining investors' money to the investors, why would you keep the lights on?

I'm wondering specifically about keeping the servers on. Server costs are much less than the cost of "keeping the lights on".

It depends on the product. CI is very compute intensive (and may be bandwidth intensive, depending on setup).

Re: Ship.io says goodbye

#26

Post by ShaneWilton »

pbiggar wrote: post #23

[Disclaimer: I'm founder of a competitor ( https://circleci.com , which offers CI/CD for iOS and Android as well as web apps, open source, etc).] I don't know why it shut down, but my guess: customers didn't want to use one CI system for their iOS builds and another for their server-side builds. This was one factor in CircleCI acquiring distiller.io (which was a ship.io competitor) last year. The history here is very…

I'm not terribly familiar with ship.io, but we use CircleCI at Tinfoil Security, and it's an excellent product.

If you're looking for a replacement to ship.io, it's definitely worth investigating. Their support is excellent, and I'm sure they'd be able to help you fill the ship.io shaped hole in your infrastructure.

Re: Ship.io says goodbye

#27

Post by grrowl »

nathancahill wrote: post #22
chrissnell wrote: post #17

Earlier quoted context omitted.

If your priority is returning the remaining investors' money to the investors, why would you keep the lights on?

I'm wondering specifically about keeping the servers on. Server costs are much less than the cost of "keeping the lights on".

I agree, even shutting down compute/cost-intensive features (i.e. the actual functionality) and leaving the login screen open might prevent a few people from losing work.

Then again, if the code is mirrored on github/bitbucket/whatever, then the risk of data loss is minimal and the product is actually all functionality.

Re: Ship.io says goodbye

#29

Post by hardwaresofton »

hardwaresofton wrote: post #8

Am I the only one that sees a failed sticky footer as a lack of attention to detail/not enough effort on the part of devs? It's surprisingly (and sadly) non-trivial to make a sticky footer (that stays at the bottom of a page, even if the page's contents are not long enough to fill out 100% of the screen), but this is something I expect just about every experienced front-end dev to know by now . For those curious abou…

Just to make sure no one thinks badly of ryanfait (or whoever manages ryanfait.com) -- this comment was in no way endorsed/sponsored by that site (just one of the first reasonable explanations google produced when I searched).

Comment is purely heavily downvoted passerby-opinion, not sponsored content.

Post reply on HN