[Disclaimer: I'm founder of a competitor (<a href="https://circleci.com" rel="nofollow">https://circleci.com</a>, which offers CI/CD for iOS and Android as well as web apps, open source, etc).]<p>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.<p>The history here is very interesting:<p>The original ship.io product was built by CISimple, and the assets were sold to Electric Cloud after CISimple shut down in 2013.<p>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".)<p>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<p>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.<p>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.<p>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.
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:<p>1. Customers don't rely on the service.<p>2. There are no customers.<p>Otherwise, why not leave the servers on for another month?<p>EDIT: 3. The service isn't automated enough to be run without human intervention, even for a month. Which would also likely create failure when it scales.
So apparently they only launched less than 6 months ago:<p><a href="https://ship.io/ship-io-launches-out-of-public-beta/" rel="nofollow">https://ship.io/ship-io-launches-out-of-public-beta/</a><p>I'm not in touch with the startup world but does that seem a short time to see if it sticks? Did they just have too short a runway?
[Disclaimer: Co-founder of <a href="https://www.bitrise.io" rel="nofollow">https://www.bitrise.io</a> , one of the alternatives mentioned on ship.io 's page]<p>Back when we started only a handful of CI services were available for iOS developers. One of them was CISimple which was later aquired and rebranded as ship.io . Our motivation to start our own service was that none of the available hosted services at the time were flexible enough to handle the projects we were working on.<p>Ship.io did improve a lot, allowing custom scripts to be executed, but, at least for us, they always seemed to be too locked down, too much of a black box.<p>This is exactly why we recently introduced our [open source CLI](<a href="https://github.com/bitrise-io/bitrise" rel="nofollow">https://github.com/bitrise-io/bitrise</a>), so that you can run your CI and other automation configurations on your own machine if you want to, and of course in the (highly unlikely ;) case we would decide to close the shop you can still export your configuration and run it anywhere you want to.<p>I remember, just a few months ago, we felt that ship.io had a spy in our team, as they introduced new features almost at the same time we did (Slack support, Deliver support, ...).<p>It's surprising they closed so quick, they had quite an active marketing team and released new features frequently. I guess this decision was not up to the people who actually worked on the product, most likely they failed to meet the (monetary) expectations of their parent company.<p>Fairwell old friend, we'll always remember you!
This is too bad. This was a useful service. Part of the problem might have been that individual accounts were free. I would have paid for this service.
Wow that was fast, I attended a conference in February this year where they advertised their Beta version to developers.
Also they released a new feature back at September 21st, it is really surprising.
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?<p>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 <i>by now</i>.<p>For those curious about how you solve this (without flexbox, which is something I'd expect frontend devs to know/remember from repeated lookups):
<a href="http://ryanfait.com/sticky-footer/layout.css" rel="nofollow">http://ryanfait.com/sticky-footer/layout.css</a>