Hacker News new | comments | show | ask | jobs | submit login

This latest shutdown inspired me to write a blog post in response[1] when I first heard about it. Although the reaction is understandable, it's a shame that developers feel compelled to adopt a scorched earth policy when they no longer wish to (or are no longer able to) support their products. These indie apps are often marketed as beautiful, wholesome alternatives to grimy corporate or open source software, but how could I possibly rely on these products for essential tasks like note-taking if they're just going to disappear out from under me in a few years? The idea that software has a lifespan controlled by the developer is, in my opinion, toxic to the market. It's just one of the many things pulling the App Store down, and one of the many downsides of living in a walled garden.

As time goes on, and as I see more and more apps simply disappear off the face of the Earth when developers deem them no longer worthy of their time, I find myself switching over to software that's either backed by large corporations or open sourced, regardless of how clunky it might be compared to "designer" alternatives. My hope is that we soon find a way to collectively monetize the latter. It's simply awful that an app can just "pop" and take so many years of developer and user time with it.

(None of the above is meant to blame Vesper or even comment on the sustainability of the app economy. It's just my sad reaction as a user and, um, app enthusiast. And props to Gruber for the introspective and humble post-mortem.)

[1]: http://beta-blog.archagon.net/2016/08/21/tool-reliance/

They should open-source the backend (and hell, the front-end, too). That way you could self-host, or someone else can provide hosting.

This. I'm surprised this is the only comment on here suggesting this. It's the most obvious way to gracefully sunset an app.

"This isn't making us any money, it's costing us money to maintain. If you still depend on it, here's the tools that will allow you to continue to depend on it"

I doubt open sourcing something moderately complex is as easy or cheap as that though, particularly if there are other technologies involved that you don't own.

It's one thing to say it should be open sourced but to put further effort into something that's already losing you money just for the love of it doesn't seem like a winning proposition.

They'd need to continue paying for their font license.

"The biggest factor is that we have recurring costs: the sync server and the licensing fees for Ideal Sans, Vesper’s typeface."

They'd need to continue paying for their font license.

I shouldn't have included the font licensing fee (and in fact have since edited the article to remove it). Our annual server fees are 15-20x the cost of the font license.

What I was thinking about was opening sourcing the app. If we do that, we'll have to replace Ideal Sans with another font. The obvious choice would be iOS's system font.

That's hardly a showstopper. They could easily remove the proprietary font when open sourcing. I doubt the heavy users of this app are using solely because the font is beautiful.

The font is not cheap either*. When you can barely get people to pay $0.99 for a industry leading app, how on earth can you justify paying so much $$ for a font. I mean switch to the closest google / open source version and call it good enough.

[1] http://www.typography.com/fonts/ideal-sans/overview/

It's $300/year from what I can see. Not free, but if you think it's a valuable part of your design, a small cost, unless you just don't have a viable business in the first place.

Or switch to a free font.

In Brent Simmons' second blog post about shutting down Vesper, he mentions that Open Source is being considered:

> Some people have asked that we make it open source. The request is getting serious consideration, but I can’t make any promises.

> The code is all Objective-C. It’s an iOS 6 app with just enough changes to keep it working on iOS 7 and beyond. It knows nothing about size classes, presentation controllers, and so on. Doesn’t even use auto layout. It’s not an example of how you’d write an app these days.


And indeed, six days later they announce their formal plans to release the code as open source


I think the other way around would actually be profitable: opensource the front-end to drive adoption, and charge for back-end access.

It's all a red herring anyway, you can't pivot without a single developer.

I use tt-rss as a feed reader, and I find it quite attractive that I own the open-source backend (which I self-host), but pay for the front end. I would be far more comfortable with service models like that, where I can know I can get at my data if needs be.

I doubt that's going to drive a lot of OSS support, if the backend is still proprietary.

I think the GitLab or Nylas model works better for open source companies: open source the whole thing (or most of it), but charge for a hosted solution if you don't want to figure out how to git clone make install.

The GitLab model is actually: open source the whole thing and offer some more exotic features in a commercial enterprise version. The hosting on GitLab.com is free and GitLab only acquired GitHost when GitHost was announcing going out of business.

Maybe you're thinking of Wordpress (Wordpress.com offers paid hosting)?

> Maybe you're thinking of Wordpress (Wordpress.com offers paid hosting)?

Yeah, I keep confusing Wordpress with GitLab. After all, both are MMORPGs. Thanks!

> I doubt that's going to drive a lot of OSS support, if the backend is still proprietary.

There is plenty of support for Google/Dropbox/AWS etc, all proprietary-backend-driven APIs. If the API is good OSS developers don't mind too much, and they can always clone it anyway.

I like the idea in theory but in reality the number of people who can get a somewhat complex backend running on their own is small and the reward (syncing notes) isn't really that compelling so I think it isn't a great idea...

Instead of sun setting the app I'd switch it over to use iCloud (free backend), make it free, and set up a public support forum. This way it'd work and there would not need to be any ongoing investment of time or money.

They should just do whatever other people want, regardless of how comfortable they are with it.

No promises, but we are looking into open-sourcing what we can.

Great, I wish you luck with it. I realize it can seem like a lot of work to do this, but this seems like something all of you loved working on, so it would at least be able to survive in some way or other, and keep some of your users happy.

Even something as simple as a basic code dump (with whatever needs to be removed, removed) would be better than nothing. I'm sure you'd be able to find a steward in someone for this project.

It's largely an artifact of the cloud dependency of mobile apps in particular. Every app has a bill someone must pay and a server or other cloud presence someone must maintain, patch, etc.

App stores also contribute in that an app without a dev account ceases to exist and can't be easily installed by anyone. So if the maintainer goes away so does the app.

In the PC era software could live forever. Even closed source PC apps can still easily be run today on emulators.

Yeah, cloud, app stores and breaking platform APIs. I know people who still use ATnotes on their Windows 7 machines, despite the fact that it was discontinued more than a decade ago.

Still, PC era shareware (the equivalent to these small apps made by a couple developers) wasn't immune to cloud dependency, particularly when they had online license validation mechanisms.

You could always crack those if need be (at least if it was even a remotely popular application). And even if for some reason you couldn't, at least you had the files locally.

If I were an indie app dev building a similar product, then in addition to all the questions of business strategy I would try to bake in graceful abandonment from the start. That is: make it a paid sync service (as Gruber would've in hindsight) but build the client such that the sync service could be easily overridden, and pointed at anything that would support a particular API. Then if I have to stop supporting the app, but I have users I still care about, I can just unlock the sync service override, publish the API spec, and give people some time to come up with alternatives.

Though I guess that doesn't solve the problem of fixing bugs in the app itself. Especially if I might not have time to babysit an open-source app.

Are there any examples, in iOS, of apps that were open-sourced and are controlled by some kind of committee or foundation and still kept up-to-date in the app store? What's the lightest-weight version of that that still keeps it totally free?

(I bought Vesper over a year ago and thought it was nice but it didn't become one of my regular-use apps. No biggie: I've long been a DaringFireball reader and I'm happy to throw a few bucks Gruber's way. Plus, I was really hoping the "quality paid apps" model would work, sigh.)

Software going out of fashion shouldn't be an issue if you take care to use applications that have open data formats, or can at least export their data to something usable by other software. Hardware became a commodity; software is on its way there too thanks to its face-paced nature and devaluation from "applications" to trendy, cheap "apps". But your data will likely always be valuable, so whatever you choose to use, make sure to have continuation plans.

There is no vendor lock-in if your data stays yours. Some inconvenience perhaps; the sort of inconvenience that comes with freedom.

And that is the reason I avoid most cloud-based solutions. I want my data to be in files on my drive, and not just in some database rows on a third-party server.

Personally, I store all my notes in plaintext org-mode files in a Dropbox-synced folder.

I think it's potentially underestimating the nature of the problem and OP's complaint to simply write off potential switching costs as "inconvenient".

For example if I've developed a whole workflow around keyboard shortcuts, APIs, whatever, for manipulating a set of data using an app, and then that app disappears, even if I have the underlying dataset it might take me quite a while to get up to speed with a suitable replacement.

All of that might argue against investing heavily in developing expertise with a closed, indie, proprietary, or even an OSS app[1]. Ultimately whenever you invest your time in developing a skillset or workflow you are inherently also obligated to evaluate the future risks involved.

[1] Despite it being OSS, if it becomes unsupported and stops working on newer OSes/platforms and no one steps up to do the non-trivial work, or host the servers or whatever, you're still in the same boat.

In this case the reason is that not only the sync service costs money, but also the custom font they use costs money. So just letting it sit there would still cost money (on top of the fee for the app store itself).

I echo the sentiment and think there's misalignment between the value and the monetization strategy for many apps.

I wrote about it as well https://arielmichaeli.com/my-thoughts-on-vespers-unfortunate...

Ultimately a lot of the sadness comes from what looks like missed opportunity IMO, which is really tough to predict.

Reading your comment, I now wonder if there's a way to sell (formally transfer) these indie projects. Like how patio11 sold BingoCardMaker thru a broker.

Then someone like you could take a swing with a different business model.

Maybe a few dollars upfront and a tiered royalty model, to minimize risk for both sides.

I've seen a few platforms attempt to become brokers for such deals in the past but to my knowledge none were incredibly (or, at all) successful...

But I do agree that it's a possible "exit" strategy.

There is a market for "life support" level maintenance of companies if they get large enough. Look at companies like CA buying (and gutting) companies who have lost their mojo. I think there is an opportunity for people to do this with smaller tech companies.

I think you'd need a certain scale of market size to make it worthwhile. And if you didn't have the size to support continued development, will you have size to support continued maintenance?

On the other hand, if the devs have just moved on, there may be a sustainable company. See https://railslts.com/

This is the CA model. Gut and offshore the workforce. It's painful for both the employees and customers, but beats seeing a product get turned off.

I think you illustrated a key problem with proprietary software, particularly that which is used for practical tasks.

Free Software puts the user first. All other forms do not.

> Free Software puts the user first. All other forms do not.

If you look at it as a programmer, sure. To most people however, "how it works" is a lot more important than how it's licensed or even what it costs.

This is where the concept of source code escrow comes from. Maybe consumers should demand something similar.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact