I found myself in the same exact position with Canvas/DrawQuest earlier this year. Everyone (including myself) was laid off a few months ago, but we'd hoped to keep the app running with the remaining revenue/cash-on-hand and volunteered time (cut short by a recent hack).
It sucks, but I think we'll see more of it in the coming months/year. A lot of the seed-funded apps/companies from the past few years simply won't represent later-stage venture opportunities, and may find themselves in a position where they can't raise additional capital but can keep the service afloat without the payroll overhead.
When people say "why not open source it", I begin to question something:
- Are you saying, "why not pay yourself to spend many hours working your codebase into something that can be, at a minimum, copied down and installed successfully on hardware that you don't control" that doesn't violate any IP and only includes code you are legally permitted to open source
- Or are you saying: "Just open up the repo as-is and see what happens!"
It seems the latter option (just dump everything) is the only feasible option for a business who cannot afford additional development, but is probably immoral and illegal (you likely don't have all the rights to ALL of the code).
The first option sounds great but if moot doesn't have money in the business to pay himself to do all of that work... are you suggesting he just volunteer a large amount of his personal time to do a bunch of free work for a failing business? I can understand why a developer would prefer to get paid for their effort (and the type of developer who wishes to work for free, by default, wouldn't be in this position and would have open sourced the project from the get go...)
For products in the hardware, gaming, platform, and OS space, I understand that a lot of code is often bought, licensed, or shared between companies in a manner that would prohibit open-sourcing the software without a time-consuming IP hunt.
However, I don't think I've ever worked at a web startup that didn't require all employee and contractor-contributed code be granted irrevocably and without limitation to the company, and the last few companies I've worked at have also required that all third-party dependencies be licensed in such a way that the company could use them in an unlimited commercial or non-commercial manner.
Everything I've worked on in the last 5+ years could, I think, be open-sourced with the flip of a switch without IP or legal issue provided the company decide to do so. In a few cases I know about, projects I worked on were open-sourced after I left without even notifying me.
Do I think it's a bit irritating and potentially somewhat immoral? Sure. I'd have liked knowing that my code was open-sourced retroactively, if for no other reason than to add it to my OSS resume.
But I've never worked in a web startup where my employer wasn't effectively free of IP-debt, or one where the "flip the switch and-open source it" method wasn't legally viable.
I think I agree with your point, though: "just open source it when it dies" is a naive argument that ignores how much work putting code out there can really be.
I think you are probably right but I am curious how many web startups you've worked for. This is something I always wonder when someone says "I've never worked for a company that does X"
That's a very solid general criticism of my "well X has been true for me" style of post. I'm not trying to imply that my experience is comprehensive by any means - it certainly isn't.
I did find it quite interesting that the concept of open-sourcing a web company's software was fraught with legal concerns, because to the best of my knowledge other people could freely open source my last six years of work output without a single IP qualm. I'm obviously not inclined to think that my experience has been entirely out-of-the-ordinary, although that absolutely may be the case.
Thanks. It wasn't really intended as a criticism, it's just something I wonder whenever I see posts of that form (and I often find myself writing posts of that form and then wonder how it'll be interpreted by the audience.)
With web startups it is probably more common that you will have a stack of 3rd party services you hook into of which may work in a way that someone else couldn't just plug their own credentials in and have it run.
Certainly not 'and have it just work', but I'm really skeptical that many web apps have such complex api dependencies that you couldn't just fudge a new one in.
Even app-engine apps have been successfully run using an isolated stack.
...and certainly most 3rd party APIs really wouldn't care; just another end user. Nothing special.
"The bad news is that the renewal rate was not high enough for us to have sufficient budget for full-time employees. After carefully considering a few different options, we are making the difficult decision to no longer employ any salaried employees, including founders. Dalton and Bryan will continue to be responsible for the operation of App.net, but no longer as employees."
Interesting. The $2.5M that mcone mentioned was venture from Andreeson Horowitz, not subscription revenue. Also, according to CrunchBase [1], their parent company has raised $7M total. I wonder if this announcement means that the parent company is shutting down, or the employees of that company are no longer working on App.net in a full-time capacity.
They renewed me without any reminder. I had forgotten about the service. That's irksome. And I'm willing to bet a VERY LARGE number of the renewals were people just like me.
There is no business there, and worse, they auto-renewed people without a single reminder it was coming.
Same here. They did offer a refund in the email. My thoughts were that I like the idea and I didn't want to hit them with a refund. I switched off the auto-renew thinking I bet they'll send me an email to say my subscription is expiring and decide then if I want it again.
I'll bet 80% of subscribers have done likewise since the emails went out and next years update will be less rosy...
As far as I understand, he turned off auto-renew after they charged him and expects to be sent an email once his account expires so that he can decide again.
It sounds like they're just letting the campfire burn itself out, and I doubt next year's renewals are all that great of a concern. They wanted to get one last renewal in (to be "profitable") under the radar before essentially announcing that it is done.
sometimes it's fucking _all marketing_, i worked at a place who burned through user acquisition and just spent that money on more user acquisition, but that's the exception, i think. ;)
Hey Matt, just to clarify, the reason you didn't get auto-renewed probably has more to do with the fact that they're billing annually combined with the fact that your credit card had expired. When billing monthly, about 4 out of 5 credit cards that are expired will just keep approving transactions that are recurring.
You may already be aware of this, but I mention it because it's a pretty common mistake to assume that expired cards will result in failed payments across the board, so if you didn't already know you may want to double check that there aren't other services you're not still paying for. ;-)
Not to mention, you still legally owe the service money even if your credit card isn't working. Many companies will automatically cancel your service, but if they don't, you're on the hook (since you did order the service).
Follow-up: They renewed me. I downgraded my account. Rather than give me until the expiration of my term, I've now been downgraded immediately to the free tier. Now I'm going to ask for a refund.
It's frustrating news because the platform never actually got to the point where it could be used as back-end infrastructure in the manner of something like, say, Stripe. In other words, I couldn't built a website where users simply sign up/in, use the service, share content, etc., and not really be aware they're using App.net under the hood. I think App.net shot itself in the foot by being implemented more or less as a Twitter clone to start with. That meant that there was constantly a branding problem -- user wonders "Why am I on Website X and they're asking me to create an App.net account...what's that?!?!"
We still need a ubiquitous social/identity/billing platform that undergirds the web, yet can be used seamlessly by devs of any particular site without exposing the guts of said service. I'm waiting for someone to actually build that...waiting...waiting...
I'm in 10000% agreement. And I know from past conversations with Dalton, that this was his larger vision too.
I do agree that starting and focusing so much on the Twitter-clone aspect was what prevented the service from moving beyond that.
It's a shame too because we do need the pipes and infrastructure that can exist without being tied to any specific platform. Build the platform later -- customize it -- but let the identity act as its own piece.
Check out https://tent.io and https://cupcake.io. There's not much going on at the moment because everybody is waiting for the next version of the Tent protocol (0.4), which will be released in a few months.
I am also excited by http://maidsafe.net in the long term, because it replaces the web altogether.
Has tent fixed the massive issues with their protocol? When it first came out, I opened about 30 issues on the repository. They basically let them all get quiet and then closed them without comment. One or two had a bunch, though.
Hi, Steve. Most of the github issues you opened (in the week after Tent 0.1 was announced) weren't "problems" with the protocol, just differences of opinion with our architectural choices. For a variety of reasons that we discussed extensively we felt (and still feel) that hypermedia, microformats, and other preexisting attempts to solve "decentralized social" aren't good solutions to the problems we're trying to solve. A few of the other issues you raised were actual implementation errors (we shipped the initial proof of concept very quickly), and to my knowledge they've all been fixed.
In the first few days after we released the first Tent proof of concept we were swamped with user feedback and a variety of discussions. We addressed many architectural questions in detail from "why not use a custom binary protocol" to "consider using ostatus, microformats" and "Consider not making claims about REST". If you're still interested in any of these topics I'd be happy to explain in greater detail the reasons for our choices.
Tent has evolved a great deal since the initial release. We've discussed most of the reasons behind the choices we made in great detail on Tent, IRC, and during monthly office hours, recording of all are available online.
> A few of the other issues you raised were actual implementation errors (we shipped the initial proof of concept very quickly), and to my knowledge they've all been fixed.
Awesome, great.
The biggest one, in my mind, is the 'one POST per follower per message' problem. The previous stance was, and I realize I'm being a little bit uncharitable with this characterization, "we want people who use the service a lot to have to pay, so we're keeping the protocol inefficient for this purpose." Is this still the way things work?
And yes, while a lot of them do come down to opinion, a service that re-invents the world in this space sends off really bad signals. It's just a different kind of lock-in. Same beef I had with App.net.
> The biggest one, in my mind, is the 'one POST per follower per message' problem.
Yeah, all distributed systems must communicate with their peers. In the worst case this means sending a POST for each message to each subscriber since each subscriber is a different server. This can be optimized by pipelining messages that were sent within the same time window.
In the best case, which is probably the most common, multiple users will share the same host and the protocol can be aware of this and add an envelope that specifies all subscribers on the host with a single copy of the message sent to each host instead of each subscriber. We plan to add this optimization before Tent 1.0.
I think the major issue with Tent was that their development efforts had always been divided between two Tent servers. Tentd, the reference implementation used by self-hosters, and their proprietary multi-tenant server that powers https://micro.cupcake.io. But in a blog post in November 2013 (https://cupcake.io/blog/2013/new-tent-server), they announced that they will stop the development of Tentd and open source their multi-tenant server. The development of https://flynn.io (another Cupcake project) will simplify the deployment of the multi-tenant server. The first preview release of Flynn was announced two weeks ago (https://cupcake.io/blog/2014/flynn-preview-release).
We're actively working on 0.4. The big challenge right now is that a number of organizations are considering using Tent is very large scale deployments for sensitive data, so we're making the transition from move fast and break things to enterprise grade reliability.
This includes everything from a solid protocol validator (future versions of the protocol will have complete validation coverage before we release a reference implementation) and a highly scalable multi-tenant server that large service providers can easily deploy. We're refactoring the server we use for hosting Cupcake users and releasing it under a permissive license in the next few months to make that transition easier.
So it's an exciting time for the core team but there isn't a ton happening on the surface just yet.
Our goal has always been to get Tent to a solid 1.0 after which the APIs could remain unmodified for several years at least (similar to HTTP and SMTP). The tradeoff is that we then need the freedom to break things between versions of the pre-1.0 versions. It's frustrating for early app developers (one of the reasons we don't encourage adoption) but will pay off once we hit 1.0
Have you tried pump.io? That sounds like exactly what you're describing. It works very well at the moment, and you could build just about anything on top of it.
Email is direct messaging. Even the current incarnation of "social networks" are much more than that, and what they could be in the future is bigger still.
The web would be a better comparison. But with useful metadata.
Couldn't better email clients and e-mail services be made that do? I'm trying to look at this from an idiot's perspective (which may not be all that far from my ordinary perspective, because I don't know a huge amount of detail about how email works).
Theoretically, but that's not part of the model today. And if you're going to innovate on that, it's unclear that you'd want to do it on top of SMTP as a transport, rather than something newer. SMTP itself provides very little in the way of assurances about identity, deliverability, etc., all of which you'd care about as you build something higher-level.
The closest thing to innovation in this space that I know of is the stuff that Gmail is doing with custom actions [1] and contextual gadgets. And even there, they are parsing the HTML-ish body of the email to trigger the behavior, which is pretty far away from the SMTP layer itself.
I'm always think "rage" startups are the most risky. App.net was based on a super small but vocal group that hated advertising in their social apps. Dwolla is a payments based rage sort of startup born from a founder who hated paying 3% of his money to credit card fees. A very small, passionate, group can convince each other that there must be enough people like them or even similar enough to dramatically change their behavior (create a whole new payment flow, try and get important and interesting information through a new source) The problem is after that 5% of passionate users you just fall off a cliff in terms of how much effort then next 5% and ultimately 95% will do.
If you think the 3% in CC fees is something felt by a small number of businesses you're so, so very wrong. Dwolla is actually doing quite well despite the fact that it's insanely hard to pay with Dwolla if you don't have an account - that's how much businesses hate the fees. They push it anyway. Programmers making SaaS products often don't understand but that 3% is often 30% to as much as 90% of a businesses margin.
@tomasien compare the success of Stripe to Dwolla over the same period of time. Look at that as proof about how many people are happy to get 97% of 1000 transactions vs 100% of 100. Not that people won't keep that 3% if they can. But it has to be equal to the CC experience.
Dwolla isn't ideal - but it's a big and growing company that's built 100% on a foundation of "try to get people to pay with Dwolla even though it's hard just to save the 3%". Things that save that 3% and can serve the entire market or a bigger percentage of it more easily* have a chance to equal or surpass Stripe's growth because of how interested businesses are in this.
I've been on HN for a long time. I've seen many app.net posts fly by. I've read the start of many articles, been to their home page and even read their "Learn more" page. I still don't understand what it is. Is it something new, or just a Facebook clone? How is it different from Mozilla Persona or OAuth?
I am apparently, as a web developer, their target market. I think maybe their disdain for marketing has caused their marketing and communication to suffer.
You might call it a social backend. Imagine Twitter+Facebook+Dropbox but with all the UIs removed, so it's just a backend datastore with APIs. Then third parties write apps that provide different UIs on that data.
But isn't Twitter without a UI or userbase just basically a database, only controlled by a third party? What's the point of that? I already have MySQL and Postgres, and they are free and open source.
It's a massive social graph + infrastructure for subscribing to data sources (i.e. other users) and broadcasting messages from one source to all subscribers (including push).
And that's just Twitter. ADN includes a lot more than Twitter does.
You can store data on app.net and share it between apps. So you can have a single contact list, for example. Or share your photos in any photo album, without managing and re-uploading the same photos for different services.
Well if we're on Twitter and I want to send you a non-public link (just between you and me) then you have to make a dropbox account. Or a Box.net account, or a Mega account, or every other kind of account you might get sent to. If we're talking on app.net, I know I can send you a file hosted there. I know twitter added inline photo support recently, but app.net had it first.
The APIs are designed for web apps to be built on. It's not really a stand-alone service, it's more like data storage & identity management for you to make web apps on top of.
You need to upload the files to some place. He's saying with app net it's possible to upload it to the network (like Twitter) itself, and not to some third party storage like dropbox/mega/box. Just like sending images on Twitter.
You have to make a dropbox account to see my file, if the file isn't public.
Edit: wait, maybe that's not true. It's even worse - anyone with the shared dropbox link will be able to get at my file even if they're not authenticated as someone I want to share with.
When I was bootstrapping my startup while working a day job, I used to wonder how to answer that question. My product was bringing in more money then the company's costs, so it felt "profitable", yet not enough to employ me full-time. Seems like there is a difference between that and something that is just plain unprofitable (where the burn rate will eventually cause the bank account to go to zero).
The software doesn't write and maintain itself. So if the revenue can't cover the expense to write/maintain the codebase (i.e., dev salaries), then the app isn't profitable because one of the major costs can't be met out of revenue at 100%.
That's what I was thinking. That's an extremely disingenuous thing to say. This is especially since, apparently, many "renewals" were just auto-renewals and does not indicate any kind of traction.
If you make money after non-employee costs, then scaling up X times will eventually be enough to cover costs -- especially with a software product where you don't need 10x more developers to earn 10x more money
I think there is a simple reason why app.net did not take off: There was no significant differentiation from twitter other than paid / no ads argument.
Indeed many people including Dalton were saying that from 2007-2011ish when the Twitter API was wide open and speculation about it's potential as plumbing ran rampant. However over the last few years, it became increasing clear that the contingent of people inside Twitter who saw it as new and amazing plumbing for the next generation of applications were losing, and the contingent who saw Twitter as a media company selling advertising with a fully controller and branded user experience were the ones who won out.
Anyone building an app on top of Twitter for anything other than personal or experimental use is a fool. Unfortunately for anyone building on top of App.net, it doesn't have the users to make it broadly interesting or significantly profitable.
However the 256-character limit in the micro-blogging service and its support for embedded links (so you didn't need to use ugly URL shorteners that hid what you were about to click-through to) and images (which did not require yet another visible URL) are very nice features.
This post is a stark reminder that startups are extremely challenging. There are many elements and, often times, a good bit of luck needed for big success, especially when you are doing something novel (http://mariocaropreso.com/post/62811446044/nonlinearities-an...).
Nassim Taleb talks about entrepreneurs as people who should be championed when they fail. They take on projects with very long odds. It is a tough life with little upside if you don't make it big. These entrepreneurs teach us a lot. We all get to learn from the path they traveled down. Dalton tried something new and it didn't work out as planned. Someone else will build on what he started and we'll all be better for it. Failure is part of our ecosystem. These situations are good reminders that those that make it big have learned from others and have often had a few lucky breaks to help them out.
I think everyone remembers Alpha, the Twitter clone. But there was also Backer (https://backer.app.net/). I looked at it a few weeks ago and I didn't understand why there was no list of currently active Backers. Actually I always been very curious about the future of App.net, especially beside the Twitter clone as I never fully grasped what you could do with it "as a platform".
Oh thanks, I didn't understood it was the list itself. When I looked at that page before, I googled a bit to see past projects and it seemed the only one I could find was the one already on that page.
Usually platforms built around some useful service or product.
For example Apple built a platform for iOS devices, Microsoft for Windows OS, Facebook Platform for Facebook social network, Amazon for AWS, Google for Android, ChromeOS and Cloud Platform, etc.
App.net did it in reverse, they built a platform and hoped that useful products and services will be built on it.
I think they had better chances if they were white-labeled Social PaaS/BaaS/mBaaS completely hidden from the end-users.
App developers would be paying for the BaaS Platform, not their app's end-users.
The idea was to be Basically.. Parse, but where the users keep shared accounts across all apps and services.
The underlying idea is good but the executions and message were lost in TERRIBLE, TERRIBLE marketing. No one knew what it was other then, "that twitter knockoff site you have to pay for".
I signed up for app.net when it first offered the paid option and was billed for the renewal, but honestly I haven't touched the site in a year. I just forgot to cancel my subscription. I really want to support it but I have no reason to engage with it.
I'm willing to support the company, so I can't understand why they don't pivot to something people are happy to pay for? I might even pay for a light social media dashboard. No reason to wind down in my opinion...
Not enough people willing to pay to pivot to something people are (possibly) happy to pay for. That's what App.net was. It had good signs of support at the start and they dove in head first -- I think a wise decision.
The odds were against them; as they are with all startups. This just happens to be their day of reckoning.
I feel as though App.net's day has come and gone sadly. I had high hopes for the platform, but I think it started off on the wrong foot, coming across as a clone of Twitter instead of what they really wanted to be. My understanding based on my Twitter feed alone is that many forgot to turn off auto-renew in their App.net accounts, many of the renewals were unintentional.
I think this could be the last year we see App.net as we all know it, unless they can pull off something magical. I personally think they should open source the code and pivot to a support model, try and move into the enterprise somehow, but that could all just be wishful thinking.
I alone wanted to see App.net succeed, but it just didn't get the traction it needed and the high price-point was a deterring factor for many developers to join. If they lowered the price to $50 or heck even $20 (which seems quite low) they would have had way more signups and I would have been more inclined to give it a longer chance/keep paying.
I always felt as though App.net was an RSS reader for consuming API's. A place where you could feed in your Facebook feed, Twitter, email and more. Sadly, the public mostly saw it as a paid Twitter alternative without the advertisements.
This is one more indictment to the idea that you can build a profitable business on consumer apps without just slapping on ads and then the revenues are so low per user that unless you have millions of users, it's probably not going to support much of a business.
The problem with App.net was that it offered nothing new. It was an alternative to existing free, established products—Twitter (and, to an extent, Google+ and Facebook).
For me pieces of infrastructure like Twitter shouldn't be owned by for profit companies. A Twitter-like public forum ought to be the town square of the web, and it should run along the same lines as Wikipedia. The data should be ours to do as we please with, there should be no purchasing access through adverts. App.net, and the insanely confusing concept of the Alpha app within it, might not have been the right solution, but they were asking the right question.
Unless you count the wave of innovation coming out of cryptocurrencies, which are really just protocols for managing a blockchain. A decentralised Twitter could theoretically be built with this model.
The only question is "who pays for the infrastructure". Wikipedia has done extremely well with its donation drives; that's very hard to repeat. App.net seems to have struggled to make users pay directly. Arguably the whatsapp charging model has worked best.
I didn't renew my App.net subscription, there really was no value for me. Checking it along with Twitter got tiresome (I was hoping someone would integrate the two into a single client) and overall everyone I care to follow is on Twitter, it was difficult to get people interested and on the App.net bandwagon.
> I was hoping someone would integrate the two into a single client
My belief is that Twitter's rules prohibited doing precisely that. There are multiple developers that expressed an interest in creating a single app for viewing both, but never did so because Twitter would have revoked their API token.
I concur with the point that they did not differentiate enough with their free competitors.
I remember being thrilled when I read Dalton initial essay on the topic and did register an account but a free one.
One reason why they failed was to reduce the barriers of entry for new users. Joel had a article[1] on in Yr2000 on the levels Microsoft went to convert users from Lotus 123.
My guess is Dalton and Co failed to think on these lines
ugh, tried to turn off auto-renewal only to find out you can't. Downgrading is the only option, and it is immediate rather than at the end of the period I already paid for. That's annoying.
As a developer on the platform who relied on the developer incentive program this is extremely disappointing. Like many other developers using ADN as a backend I relied on that to make my application free and got a small amount of money each month if people voted for it with the program. It wasn't a significant amount of money but it was enough to pay for my developer membership. Now I imagine even fewer users will be on the service and I have very little incentive to keep improving the application.
It was a really hard business model to support and get to work. You are paying for the forward belief that the network itself will be strong enough to ultimately justify the costs, but over time if that belief isn't met (and it wasn't) then you will lose subscribers.
I give Dalton and Brian kudos for trying. Ultimately I think the lesson here is users simply aren't offended enough by ads that they would be willing to pay a subscription service to avoid them.
I'm not even sure the dollar price was the issue. But I would have to rebuild things like "people to follow", get used to the new interface, have the risk that the platform doesn't survive - a lot of implicit costs. What could be working is to offer a paid tier for an already existing service like Twitter - but unfortunately they have a strong incentive not to. Because it would mean that their ads would stop reaching the very people that the advertisers are interested in - the ones who are willing to spend money.
Perhaps its true purpose wasn't pitched strongly enough. My impression as a HN regular was that it was indeed just a paid twitter, and as such I paid it no mind.
I really enjoyed ADN for quite a while. I do think though that recently there were some opportunities to make a shift to provide more visible and direct value for users if they clarified to the outside world they had many different uses.
I could've seen them go down more of a road like Zoho.
It makes no sense to say the renewal rate was high enough to remain profitable and self-sustaining, but you can't retain any of your employees. It sounds to me like they didn't have enough renewals to remain profitable and self-sustaining at their current burn rate, and decided to reduce the burn rate significantly in order to remain in existence. Overall, that's bad news, not good.
As discussed more than 1 year ago (https://news.ycombinator.com/item?id=4346303), the (very) hard times they had signing people up, with constant posts on HN without much effect, should have been a strong indicator people didn't actually need this.
Sad news for App.net :( Unfortunately, I never understood what is/was the point App.net. Somebody did ask that once on Hacker News but the best answer was "it was kinda RSS feed but they now changed focus so they lost me".
Fundamentally, App.Net is a platform that provides a number of services, including Twitter-like one-to-many messaging, private one-to-one and one-to-many messaging (like Twitter DM on steroids), many-to-many messaging (like IRC chatrooms), file hosting, and some less-obvious features like messages generated by and for machine consumption (that are never seen by humans), etc.
These are the nuts and bolts that can be used to build a Twitter clone (which App.Net did and which is the primary "product" that most of their users used), a Dropplr clone, blogging a la Octopress, personal memory logs (like Ohai[1]), Photo story sharing apps like Sunlit[2], etc.
Heck, you could even use this to build a Chess app that lets you play remotely with other players, that automatically records every move ever made, and that lets you access your games and history from any device. Basically, anything that involves sending messages (of up to 2k, plus various bits of metadata) between two or more parties and persisting them could leverage App.Net to power itself.
Of course, that's part of the problem. They positioned themselves as a platform, which meant they didn't market themselves very well to end users.
I signed up at the start, was excited for it.. but even after a few months all that was really going on there were people posting about how awesome we all were for being on app.net, nothing of substance
It was Andreessen Horowitz who put money into App.net right? They're investors in Facebook though, so isn't there a conflict of interest? Anyone know why they'd invest in App.net?
Leo jumps on whatever is new and then as soon as his attention is distracted he moves on to something else. The list of things that he as said he "loved" and then never mentioned again would be endless...
I completely agree. However, he's still posting on Twitter every day, as far as I can tell. He regularly posts on Google+, even now. It says something if the social butterfly of the tech world has abandoned your service.
Remember rev="canonical"? It was to save us from the tyranny of bit.ly and co. Geeks rallied behind it.
Remember Open ID? It was to save us from the tyranny of Passport.NET and co. Geeks rallied behind it.
Remember Diaspora? It was to save us from the tyranny of Facebook. Geeks rallied behind it.
Remember App.net...?
The history of geeky "open" (or ad-free or whatever) alternatives to commercial social media services is littered with corpses. What geeks never learn is that social media services can't survive if the only appeal of the service is some righteous motivation that only they care about.
Sooner or later even geeks realize that using a "better" service to talk to nobody isn't very useful.
I know it seems easy to be Captain Obvious now that App.net is falling apart, but just you watch. Soon enough it'll happen again (and then again, and again).
What is disappointing about App.net was that it had the potential to be a set of pipes and a broader infrastructure rather than being simply yet another social network. And that's what my true hope for App.net was.
Marketing is a huge part of the success of a new paradigm. App.net was "marketed" with a practically blank home page ("one login many applications" - which applications?), and a nondescript niche Twitter clone on one of its subdomains.
It had no chance at all. Where was the evangelism? Where were the presentations, demos, and the other useful apps built on this platform?
I'm a developer and I did hear about App.net when the buzz was at its peak. I remember going to their home page and wondering "wtf is this?", then checking alpha.app.net on a couple of occasions, finding nothing of interest and that's it.
That wonderful arrogance that the world will care about your project because you're somehow "right" has killed many tech efforts and will kill a lot to come yet.
I see real value in using App.net as an identity provider so that I'm not relying on something shaky like Twitter or Facebook but I can still get the benefits that come with an external provider (lower signup friction, 2-factor auth for users that want it, less overall damage if site is hacked). But (a) their marketing is so weird that I don't really know that I can do that, and (b) their onboarding for end users sucks, so I'm losing people telling them to sign up through them.
I think part of the problem was the initial strategy that required all accounts to be paid limited the userbase to the point that it wasn't worth experimenting with.
I don't know how you get around that challenge of building a mass userbase, keeping the framework open and yet still being sustainable. But that's a separate challenge from what you described.
Your other examples are good but OpenID is somewhat murky: the concept was good but the design was completely misconceived. The basic ID primitive should have been the email address instead of a URL — far fewer people have a stable homepage or think of its URL as representing their identity – and the entire system needed to be both simpler to implement and built around delegation to avoid requiring large companies to jump on board before anyone could adopt it.
That ship may have sailed – I think there's still hope – but I think there would have been a real chance for success had BrowserID shipped before everyone was pushed onto Google / Facebook / Twitter because those were the only options which didn't turn into a support disaster.
> Remember Diaspora? It was to save us from the tyranny of Facebook. Geeks rallied behind it.
No they didn't. Geeks resented Diaspora's funding and high profile and mocked its slow pace of development and initial security issues.
> What geeks never learn is that social media services can't survive if the only appeal of the service is some righteous motivation that only they care about.
Diaspora's somewhat overblown profile was a consequence of it being featured in the New York Times and its Kickstarter appeal being unexpectedly funded by thousands of ordinary (perhaps slightly naive) people.
Measured by how often I do use Google to log into things, I'm not sure why the existence of providers is proof that it didn't fail. The login method that Google promotes doesn't seem to be openid but something that's easier to use (and only works with Google).
It sucks, but I think we'll see more of it in the coming months/year. A lot of the seed-funded apps/companies from the past few years simply won't represent later-stage venture opportunities, and may find themselves in a position where they can't raise additional capital but can keep the service afloat without the payroll overhead.