App.net State of the Union
blog.app.net
blog.app.net
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.
There is quite a trail of minor problems:
Eg.
Legal implications with investors/shareholders/etc
(Unlikely but) Potential security issues
Fixing the code to a level that other people can run it
Documenting the code to a level that other people understand how to run it (eg dependencies on services around it)
And i am pretty sure there are many more.
All solvable problems but in most cases come in a moment when a founder has already ran too far and is out of cash/time/energy to tackle those.
- 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...)
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.
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.
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.
Did these guys burn through over $3 million in less than a year? They got $2.5 million in August 2013. (http://techcrunch.com/2013/08/14/app-net-new-funding/)
There is no business there, and worse, they auto-renewed people without a single reminder it was coming.
I emailed them and gave me a refund.
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. ;-)
I'll bet 80% of subscribers have done likewise since the emails went out and next years update will be less rosy...
I was waiting for them to do more with app.net than just a Twitter clone. I guess I'll be waiting a long time!
It would be really interesting to take a look at the finances, see where the money went.
File storage: https://directory.app.net/app/182/filebase/
Mobile group chat: https://directory.app.net/app/238/whisper/
Personal memory log: https://directory.app.net/app/229/ohai/
IRC style chat rooms: https://directory.app.net/app/145/patter/
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...
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.
[1] https://developers.google.com/gmail/actions/actions/actions-...
The web would be a better comparison. But with useful metadata.
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.
I am also excited by http://maidsafe.net in the long term, because it replaces the web altogether.
EDIT: turns out it was 18, not 30: https://github.com/tent/tent.io/issues/created_by/steveklabn...
There hasn't been much updates on Tent since the last office hours in January (https://tent.io/officehours/2014-01-28), but Daniel said a few hours ago that they will announce May office hours in the next few days (https://micro.cupcake.io/posts/https%3A%2F%2Fdaniel.cupcake....).
I'm really excited for the new features in Tent 0.4 (https://github.com/tent/tent.io/issues?labels=v0.4&page=1&so...) and I can't wait to self-host Tent on the new multi-tenant server!
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.
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.
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.
Anyway, good luck. My efforts in this space have failed and you're still plugging away, so...
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
*disclosure: I run such a company
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.
And that's just Twitter. ADN includes a lot more than Twitter does.
And regarding "just send the link via DM", that's currently not possible any more: https://dev.twitter.com/discussions/23044
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.
Sure, the recipient might share it, but s/he could also just download the file and share that, so you haven't lost any security.
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.
They are profitable as long as they don't pay anyone a salary. That hardly counts as profitable. How can the service grow?
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
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.
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.
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 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'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...
The odds were against them; as they are with all startups. This just happens to be their day of reckoning.
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.
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 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
[1] http://www.joelonsoftware.com/articles/fog0000000052.html
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 believe there's more to it than that, but the price being too high was a major contributor.
They tried hard to build an 'elite' club of rich twitter users, and it wasn't clearly going to work. Because rich people can not listen to each other.
PS: i happen to be rich twitter user myself haha! i did pay them $29 and spent like a week there and quitted., because no one'd listen to me. ;)
I had read a lot about what Dalton believed and agreed with him. My $29 seemed paltry in the long view if he would succeed.
I'm saddened by the current state of affairs. But I am glad I helped give him a shot at something I was unable or otherwise unwilling to attempt.
I could've seen them go down more of a road like Zoho.
and really be outright focusing on an application or conduit infrastructure.
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.
[1]: http://ohaiapp.net
[2]: http://sunlit.io
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.
That's what App.net did --- they built out a complete product offering to only be marginally different from the alternatives.
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.
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 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.
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.
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.
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.