Echo - hyperlocal messaging app
Hugh Mason
My name's Nathanaël. I'm a founder over at Echo
we're working on a hyperlocal messaging app (3 months in) which basically allows people to crowdsource local information.
Here's our homepage: http://echosystem.im/
We'd love to explain our product in a bit more detail, to hear what you think
Nathanael Silverman
To set some context for feedback, were you following any particular development methodology for this project, eg Lean Innovation?
Hugh Mason
we've certainly applied some of the Lean philosophy. We launched early and we iterate quickly. We've just now decided to stop working on features and will attempt to validate a growth model before tackling monetization.
Nathanael Silverman
I got a sense from your videos on nReduce that you've put really focused energy into product development. I wasn't sure if you've done the customer discovery thing as, say, Ash Maurya would suggest it can be done rigorously in his book Running Lean.Is that right, or have I misunderstood where you're at?
Hugh Mason
> That is correct. Only now are we really starting to focus on finding a growth pattern, and from there we'll try to find some customer segments that work well by monitoring the content that's submitted to our app and by running targeted advertisements that bring to targeted land pages.
stage 3 in the list I outlined.
If you can force yourself to do it (and you need to go in being
prepared to throw away all you have created so far), I would really
recommend holding back from moving from stage 2 to stage 3 and
spending some focused energy on stage 1, ie customer discovery.
Why? Because only that will tell you if you are actually addressing a
problem that is worth solving. Otherwise you risk putting a lot of
energy into selling a solution that still isn't clearly addressing a
problem.
I blogged recently about a kids messaging service that got this
totally right, IMHO:
http://t.co/Jq5dMHrF
Nathanael Silverman
Why? Because only that will tell you if you are actually addressing a
problem that is worth solving. Otherwise you risk putting a lot of
energy into selling a solution that still isn't clearly addressing a
problem.
Hugh Mason
> Echo doesn't address a problem per say. Just like Twitter for instance didn't and doesn't address a problem directly.
In 2002 I visited New Zealand for the first time and, in a little
rural museum, there was an exhibition of postcards from about 1905.
The pictures on the postcards weren't that surprising but I burst out
laughing reading the messages. They were EXACTLY like modern tweets. I
think human beings have long wanted to send short messages to each
other - it's just that technology didn't allow that for a lot of the
20th century. (Little known fact - around 1905 in central London there
were FOUR postal deliveries a day and people had almost as dynamic an
exchange of short messages as we do today).
> But we know already that people are very enthusiastic about our app, and would like it to take off, that is, for people to share various things on it about what's happening locally.
> That's another thing, Echo can help with a lot of things. It's already being used to promote events, to post local ads, to inform about store availability when a new hot product comes out, etc, etc.
might be the key? Again, only customer discovery - not marketing -
will tell you what that is and which preciously-crafted features you
should throw away to get laser-sharp focus.
Think of Instagram - IMHO it solves a problem ("I'm not a great
photographer but I've just seen something cool and I want to share it
with my friends") - and that is all it does. It doesn't try to be a
family photo album or a gallery service for pro photographers. There
is less functionality on the version of Instagram I have now than it
had when I first started using it (no swing and tilt lens effect, for
example).
Here's a test: if you go to a real customer who has never used your
app before, have them use it, then ask them how they would sell it to
a friend, what do they say? They will get it "wrong" in your opinion
but it really isn't your opinion that matters here - it's the way that
they get it "wrong" that will tell you what is the "right" focus for
your app. Maybe just do that REALLY well and throw away the rest?
Nathanael Silverman
So Meng and I have different views on this.
In 2002 I visited New Zealand for the first time and, in a little
rural museum, there was an exhibition of postcards from about 1905.
The pictures on the postcards weren't that surprising but I burst out
laughing reading the messages. They were EXACTLY like modern tweets. I
think human beings have long wanted to send short messages to each
other - it's just that technology didn't allow that for a lot of the
20th century. (Little known fact - around 1905 in central London there
were FOUR postal deliveries a day and people had almost as dynamic an
exchange of short messages as we do today).
> But we know already that people are very enthusiastic about our app, and would like it to take off, that is, for people to share various things on it about what's happening locally.
So what's holding them back?
> That's another thing, Echo can help with a lot of things. It's already being used to promote events, to post local ads, to inform about store availability when a new hot product comes out, etc, etc.
Could it be that focusing on the ONE thing that it does uniquely well
might be the key? Again, only customer discovery - not marketing -
will tell you what that is and which preciously-crafted features you
should throw away to get laser-sharp focus.
Here's a test: if you go to a real customer who has never used your
app before, have them use it, then ask them how they would sell it to
a friend, what do they say? They will get it "wrong" in your opinion
but it really isn't your opinion that matters here - it's the way that
they get it "wrong" that will tell you what is the "right" focus for
your app. Maybe just do that REALLY well and throw away the rest?
Meng Wong
So Meng and I have different views on this.
Hugh Mason
What would you say Twitter solves then? We already had e-mail and text messages before Twitter came about.
Don't you think people have a vested interest in local news and would like to share information locally themselves sometimes? I suppose Echo does solve something, I just wouldn't call it a problem.
> But we know already that people are very enthusiastic about our app, and would like it to take off, that is, for people to share various things on it about what's happening locally.
So what's holding them back?
Nothing. They're doing it already, but as any social app the more the merrier, which is why we'd like to focus on growth.
Don't let the numerous use cases detract you from the one thing that Echo does (and tries to do well): spread messages locally. The rest is up to the users.
Combining a very specific use case with our current technology (relaying messages through echoes, dynamic radius depending on an area's activity, etc) would make little sense and would almost certainly be an overly complex solution, don't you think?
People using our app today would describe it as a general messaging tool, not as a specific problem solver, guaranteed.
I fail to see how going up to someone who's never used the app before beats analyzing 15k messages who've already been sent through the system by real users in figuring what our app really is about.
Meng Wong
Combining a very specific use case with our current technology (relaying messages through echoes, dynamic radius depending on an area's activity, etc) would make little sense and would almost certainly be an overly complex solution, don't you think?No I think it is the only way you are ever going to boost uptake. Right now I don't have a simple way to explain to non technical friends why they should use your service. That's a problem. By all means keep the other use cases in the background but get deep engagement in a niche first and then work out would be my suggestion.People using our app today would describe it as a general messaging tool, not as a specific problem solver, guaranteed.So there's your problem. In the way they are describing it, your current users are positioning your tool as competing with every other messaging tool out there. Instead of fighting one focussed battle for attention, you are penned in by adversaries on all sides. As a startup you don't stand a chance winning that war. You need to pick one battle at a time, commensurate with your resources.
Josh Russell
(yep I lurk here!)
If you want to ask questions I'll be as open and frank as possible!
–Josh
> You received this message because you are subscribed to the Google Groups
> "Open Frog (JFDI.Asia)" group.
> To post to this group, send an email to open...@googlegroups.com.
> To unsubscribe from this group, send email to
> openfrog+u...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openfrog?hl=en-GB.
>
>
Hugh Mason
(yep I lurk here!)
If you want to ask questions I'll be as open and frank as possible!
Rodrigo Martinez
IMHO and based on my experience the key to success is the right mindset. We can call it a "success mindset". Please do not get me wrong, I am not saying hard work, etc. are not important (more on that later).
What I am saying is that the success mindset is the "root", which will bear the right type of "fruit" in the right "season".
Enthusiasm is definitely part of the "DNA" of such a success mindset. The problem is it can also work against you.
What are you enthusiastic about? Are you enthusiastic about YOUR product or are you enthusiastic about delivering the best, out of this world, experience to your end users?
And even before that…What is your compelling REASON to go down the entrepreneurial path anyway? Is it to accomplish a financially free type of lifestyle (enjoy what you want: dinners, travels, etc. when you want it)? Is it to provide your parents with more than what they gave you? Is it to make an favorable impact on those less fortunate (in terms of opportunities) than us? That is a question which each one of us must answer individually.
Nevertheless the reason is critical in achieving success, and the greatest companies in history have been built on this foundation.
Another part of the DNA is passion. Are you passionate about technology or are you passionate about how you can use the technology to improve people's lives in so many different ways (does this ring a bell, 12/9?)?
From the right root with the appropriate DNA you will get the trunk, branches, leaves, etc. You will get the Lean Startup method (sorry if I am not using the right name), the product development cycle, the research, etc. It's not even about the money or funding, though, you will probably need some. Neither is it about hard work, though some work is required, which you can even delegate in some specific situations. It is not even about your educational background!
Sorry, perhaps I got carried a way a bit, it was all Meng's fault when he used the word "enthusiasm" ;-).
Bottom line, start with the right success mindset, keep the faith (non-religious) and the rest of the tree will "kick in". And remember to persevere long enough in the process!
Cheers,
Rod
PS: This is a very brief overview on the subject. There's much more to it than can be "squeezed" into a mailing list. ;-)
Josh Russell
I wasn't going to chime in on the discussion about the problem Twitter
solves. (it definitely solves lots of problems we didn't know we had.
can you imagine if you had to use Facebook as if it was Twitter? ugh.)
Anyway, yes, I always assume good faith, and you have to remember that
other people's viewpoints are such for a reason. They literally are
viewing from a different angle!
I just answered a bunch of questions for The Next Web and TechCrunch,
not sure if they'll go up, so if relevant I'll post here. (if not
relevant, sorry for the noise)
TNW
===================================
> You note that people can contact you if they are interested in learning more
> about your plans etc. Are you looking to sell or have it taken over by
> someone else?
I would love to have the service continue to run, we only just started
and there's tons of opportunity to 'add' to Twitter's experience. If
that happens inside someone else's product or company then that might
make it possible.
> What were the issues that stopped you from fulfilling your goals?
Development was slow, mainly due to some of the technology choices we
made early on. That's a huge learning point for me! There was much
needed progress under the hood (scale, efficiency, robustness), but
not not enough on the front. One of the challenges of playing in
someone else's playground. Our environment is a browser plugin, that
loads a webapp as javascript, on someone else's frontend code, in
multiple browsers, on multiple domains, with multiple account support,
tricky security... and yes heavy reliance on a third party API and
third party social graph.
> Was Twitter's position on its API etc a factor in your decision?
Not for us. Twitter have been very supportive and encouraging from
very early on. Even giving us a heads-up when there's a change coming
that might effect us. We couldn't ask for more than that, especially
knowing how many developers they have to engage with! Because Bonfire
actually keeps people on twitter.com longer, user eyeballs on the
stream exactly where Twitter want them, we work very well *for*
Twitter, rather than pulling users elsewhere. This was always the
plan, Twitter is focusing on the webapp (and official mobile apps), so
how could we make *that* better as a third party. In some ways we were
their live labs, exploring engagement ideas.
> What are you going to do now?
I've managed to find a great group of people in my extended team, and
I have a few big ideas. Having learned a lot running Bonfire as a solo
founder I'm now well armed to go again. I've also created a set of
rules, or creative constraints, that should help defend against a lot
of common startup problems. So keep an eye on http://joshrussell.com
;)
>
> Hope these questions are okay!
Great questions, thanks for the interest!
TechCrunch
===================
Hey, here's some short answers…
Lack of further funding?
Our funding story isn't typical (is there a typical story?), we raised
to build a prototype but of course had to launch too. This meant we
needed to launch ASAP (earlier than planned) and start the fundraising
process again pretty quickly. That takes time, so we got out of sync
with a traditional grow-raise-build-grow-raise cycle. We had the most
interest from later-stage funds here in the UK, but we weren't ready
for them to invest yet.
Tricky search for talent?
Always Be Hiring, one of my new rules. If someone awesome comes along,
hire them. There is huge competition at the moment, of course, but
there's more to it than that. You need to hire people that share a
passion for the product and vision, and that are 'startup people'. By
that I mean people that want to be an influential part of something in
it's early years. Team is everything.
User traction low?
It was bigger than some. But as I allude to in our post (
http://bitly.com/OdjIQl ) we weren't able to move fast enough to
capitalise on everything we learned, this had an impact on growth. But
we were also placed differently to most apps, being a plugin on
someone else's site, having no social objects to share (UGC like
photos), and a viral ceiling since Bonfire is based on mutual Twitter
follows (that's roughly 40 people on average, Bonfire could be thought
of as 'Path for Twitter'). So our viral coefficient isn't typical
either. Further down the roadmap we planned to open up the platform so
third parties could build better Twitter messaging into their apps,
and to allow further private functionality missing in Twitter, like
groups, and private photo sharing.
What gives?
We tried something hard. Bonfire is deceptively complex, and we made
it look very simple from the outside. So a combination of complex
technology, longer term revenue plans than we had time to demonstrate,
and difficult hiring were all issues. Good lessons learned.
Hope that's useful, I can definitely elaborate more in a post at some
point if it would make good reading,
Thanks dude!
Martin Bähr
> I just answered a bunch of questions for The Next Web and TechCrunch,
> not sure if they'll go up, so if relevant I'll post here. (if not
> relevant, sorry for the noise)
for sharing.
> Our funding story isn't typical (is there a typical story?), we raised
> to build a prototype but of course had to launch too. This meant we
> needed to launch ASAP (earlier than planned) and start the fundraising
> process again pretty quickly. That takes time, so we got out of sync
i also got the impression that the technology side was more dificult
than you expected. is that correct?
of course hindsight is 20/20. could you have known? was there something
that you neglected to do that could have lead to a better outcome?
(note that i think that this kind of question is easy to ask but hard to
answer. most of the time when i analyse where i made a wrong turn i find
that given the knowledge i had at the time i couldn't make a better
decision, and once i realise that i find it easier to move on.)
greetings, martin.
--
cooperative communication with sTeam - caudium, pike, roxen and unix
services: debugging, programming, training, linux sysadmin, web development
--
pike programmer working in china societyserver.(org|net)
foresight developer community.gotpike.org foresightlinux.org
unix sysadmin (open-steam|www.caudium).org realss.com
Martin B�hr http://societyserver.org/mbaehr/
Meng Wong
Was Twitter's position on its API etc a factor in your decision?
Not for us. Twitter have been very supportive and encouraging from
very early on. Even giving us a heads-up when there's a change coming
that might effect us. We couldn't ask for more than that, especially
knowing how many developers they have to engage with! Because Bonfire
actually keeps people on twitter.com longer, user eyeballs on the
stream exactly where Twitter want them, we work very well *for*
Twitter, rather than pulling users elsewhere. This was always the
plan, Twitter is focusing on the webapp (and official mobile apps), so
how could we make *that* better as a third party. In some ways we were
their live labs, exploring engagement ideas.
Strategy Letter to the Twitter Third-Party Ecosystem
The protocol pendulum is about to swing!
This essay explains the history of the protocol pendulum and suggests to the Twitter ecosystem what they could do about it, in the six months between now and March 2013.
September 8, 2012: Twitter's Power Grab
Sarah Mitroff of Wired reports that Twitter has decided to consolidate power. Its API is changing, putting third-party clients at risk. (She mistakenly names TweetDeck as a third-party client; they were acquired by Twitter, so they're safe. But the fact that they dropped LinkedIn updates after the acquisition is telling.)
If I were Nick Carr, I would see this as one of the risks of digital sharecropping.
If I were Geoffrey Moore, I would see this as a power struggle between a gorilla and a bunch of chimps.
If I were a naturalist, I would see Twitter as a shark and its third-party clients as remoras.
Now the shark has just decided that its commensals are really parasites, and wants to get rid of them.
Lessons from History
All of this has happened before and will happen again.
Geeks of a certain age will remember Watson: a fine third-party extension to Mac OS. It made a respectable shareware living, complementing the base OS with features so useful it won an Apple Design Award the year it was launched. The very next year, Apple decided that those features really did belong in the OS, and with its release of Sherlock 3, squashed Watson flat as a penny under a steamroller. With friends like that, who needs flattery?
That was ten years ago.
Let me explain my perspective. Paul Graham coined the phrase "the periodic table of protocols." After Mendeleev, chemists characterized the known elements and discovered new ones. Similarly, there exists a small fraternity of Internet architects and engineers who maintain messaging systems and devise new media. For a time, I was one of them.
I first got on the Internet in 1992. I have watched the pendulum swing time and time again: between open and closed, between free and proprietary, between centralized and federated, between the walled garden and the bazaar.
Tim Wu's The Master Switch: the Rise and Fall of Information Empires tells the story of how the pendulum has swung back and forth for every medium we know today, from film to radio to TV.
Its lessons are important for new media. Email is a medium too; so are online video, instant messaging, and Twitter. The periodic table of protocols has many squares, and each square has its isotopes and allotropes.
Internet Media: Open versus Closed
Some media are open. Some are closed. Email is fundamentally open. Even though most people have an email address at gmail.com, hotmail.com, or yahoo.com, any person can register a new domain and get an email address with their name on the left of the @ sign, and their organization on the right. I, for example, am meng...@pobox.com, which is an email hosting service I co-founded almost 20 years ago.
In the world of Twitter my address is just @mengwong. In the language of email, it would have been meng...@twitter.com. But Twitter has gone and done a clever thing – they assumed the entire namespace in a move as deft as any magician's sleight of hand.
By allowing my handle to be just @mengwong, Twitter (the instant messaging concept) has been co-opted by Twitter (the company), which attached an invisible, implicit "@twitter.com" to every Twitter handle, instantly arrogating to itself the sort of power that in other industries people like Ted Turner have to work entire lifetimes to amass. And they didn't even mean for it to turn out that way – it just happened. @ messaging was a user-led innovation, not a Twitter design.
Twitter doesn't have to be a monopoly. Take online video. It looks like an oligopoly between YouTube and Vimeo and Ustream and Justin.tv and a dozen other services each serving their own niche. But if you really wanted, you could be free of all of those service, and offer video directly from your own broadband connection on BitTorrent.
So there is a spectrum that runs from open-source / open-standard / fully-federated, to a wholly proprietary walled garden. Every medium can be located somewhere on that spectrum.
What does it mean that email is federated and open? In theory anybody could establish an email server, a first-class entity in the world of ports 25 and 587, ranking equally with Gmail and Hotmail. In practice most people hand the job of running the email server to somebody like Gmail, either by registering for an email address @gmail.com, or by registering their domain and then hosting that domain with gmail.
What about the front-end? In theory anybody could write their own email client: Outlook and Mac Mail are just two "MUA"s among many. (MUA, or Mail User Agent, is the technical term for an email client.) In practice, most people just use whatever software happens to be on their computer, or they use a web interface like Gmail's.
So Gmail has produced an end-to-end, vertically integrated, email offering built on top of open standards: a client (www.gmail.com) which speaks open-standard HTTP and HTML, and an inbound server to receive mail (smtp.gmail.com) which speaks open-standard SMTP.
If you don't like Gmail's web interface, you don't have to use it. Google offers open-standard POP and IMAP endpoints for your native client to talk to.
If you don't like the @gmail.com domain, you can register your own, and still have Google run the domain in the back end.
And if you don't want to use Gmail at all, you can run your own, free, opensource email server software – sendmail, qmail, postfix – and run your own opensource email client – Thunderbird – or even write your own, after reading the standards yourself. The RFCs are out there, free to download.
Same with the web. Anyone can bring up a web server; in fact, every Apple laptop comes with a free one built in. And Firefox is opensource.
Is Twitter like email and the web? No. You couldn't bring up your own Twitter server if you wanted to. All the third-party clients talk to Twitter using its API. Take your iPhone (if you have one) out of your pocket and go into Settings: you can set up any email service you want, with a username, password, and server, but when it comes to Twitter, you get to enter the username and password that you use for, well, Twitter. There is no choice for server.
That, in a nutshell, is the difference between open and proprietary.
XMPP offers an interesting lesson: where instant messaging used to be closed, XMPP turned it toward openness. And "don't be evil" Google adopted it for Google Talk. Where XMPP is synchronous and private, Twitter is asynchronous and public. (The periodic table of protocols is built on attributes like these. I could enumerate and analyze every protocol and medium, but I will spare you.)
Today, the closest thing to an opensource version of Twitter is status.net, previously laconi.ca, now identi.ca.
Similarly, Diaspora and Friendica are opensource alternatives to Facebook.
These alternatives haven't had much traction – yet. That could be about to change.
A Magna Carta Moment for Twitter
Twitter announced its API change last Wednesday, sending shockwaves through the ecosystem of third-party apps. Like Watson relative to Mac OS, all these apps depend on Twitter. The third-party app developers (who I will call TPADs for short) are like planets revolving around the sun. In Geoffrey Moore's language, they are chimpanzes next to a gorilla.
(Want to see what happens when the gorilla yanks the chimps' chain? See Twitterlocal's home page. )
Some people might not have much sympathy for the chimpanzees. It's a free market; the Internet is a libertarian paradise; and if Twitter wins, why, so be it: more power to them.
But not everybody agrees. The TPADs, of course, disagree. And some strain of public policy tracing its roots to the Sherman Antitrust Act of 1890 believes that monopolies need to be curbed.
But I don't see the US DoJ getting involved in a protocol skirmish anytime soon. Microsoft was the last big target of an antitrust action: that was ten years ago, and look how that turned out.
Besides, the Department of Justice is a blunt instrument. 21st century problems deserve 21st century solutions.
We can all understand Twitter's commercial motivations for their API change. They want to make money; they want to lock out what they perceive as the competition, and when the MBAs at Twitter were brainstorming solutions to this "problem", they must have stopped at the first idea: iron fist of control.
To be fair to Twitter, it's not easy to build reliable Internet-scale messaging infrastructure. Millions of dollars have gone into building Twitter, and it's only fair that the company should make money and the investors should see a return.
But at what cost, and at whose expense? What Apple did to Watson was widely regarded as a rotten move, and I want to believe that whatever deities watch over the evolution of the Internet look on that sort of monopolistic power play with disfavour. Let this essay be an offering to them.
I think there are better ways to play the game. I think this is a golden opportunity for the Internet polity in general, and the Twitter ecosystem in particular, to push the pendulum toward openness. Everybody wins in the long run – the TPADs, the public, and even Twitter.
If the Internet were a country, the third party app developers would rise up and argue that The Government Should Do Something. But the Internet is not a country – there is no tax revenue, and there is no democratically representative body charged with the allocation of that tax revenue toward public goods.
On some level this situation can be read as a governance problem. The IETF is kind of like a legislative body, but the ICANN isn't even close to being an executive branch. Who pays for public goods? The opensource folks do, in kind.
The state of the Internet isn't at the point where we can even talk about branches of government. We're still a few centuries behind.
Back in the year 1215, a handful of individuals found themselves in a position not dissimilar from Twitter's TPADs today. Playing the role of Twitter was King John, and playing the role of the app developers were his barons.
It could be time for a Magna Carta moment: a starting point on the road that leads from a monarchy to a republic.
What can the barons, the TPADs, do?
Let me lay out one possible future for the Twitter ecosystem.
A Possible Future
The Third Party Application Developers, the Status.nets, and the Friendicas of the world should take Twitter's great advantage – the unitary namespace – and use it against them. They should develop a shadow network that embraces and extends Twitter's.
They should make it free and open, but also monetizable. Advertising is one possible revenue model but not the only one.
They should build toward a level playing field, where each player can monetize in its own way, and share in the riches of all the others. This is an example of an industry regulating itself – not as a monarchy but as a republic. Monarchies centralize power. Republics decentralize power.
Why shouldn't every third-party Twitter app, every Twitter client, also be a peer and a server? At the end of the day, Twitter is merely a keyword-oriented asynchronous message-passing directed acyclic graph. A DHT (Distributed Hash Table) is an ideal P2P architecture for implementing a keyword-oriented asynchronous message-passing DAG.
In the long term, the P2P DHT model makes everything cheaper. Maybe Twitter's massive back-end server farm isn't actually necessary. Skype and Bittorrent wouldn't exist if not for P2P technologies. Why not bring that architecture to Twitter? As a matter of fact, I'd be surprised if some engineering team within Skype hasn't already developed a Twitter-smasher, only to have it sidelined due to political intrigue at the highest levels of Microsoft's palace hierarchy.
There are already open alternatives to Twitter just waiting for their turn. Status.net/identi.ca, Friendica, Diaspora, and other champions of the Open Stack are natural candidates for Twitter TPADs to interoperate with.
In the long term I would like to see a P2P DHT network of intercommunicating peers, serving a distributed social network, within which the Twitter medium is represented. As an interim measure, as a way to get there, the TPADs could bring up the mother of all IRC networks: big enough to scale to 10 million users, federated across all the TPADs, and operated according to the same sorts of peering agreements that the Internet and today's IRC networks run on.
(When Twitter first came out, I laughed and said: "they've reinvented IRC!" Most people had no idea what I was talking about. They had never used IRC. But it just goes to show that every generation thinks it is inventing sex for the first time.)
The interim network doesn't have to be IRC – it could run on top of XMPP or Status.net or Friendica. And interim networks have a way of turning into the permanent networks, just as interim administrations have a way of turning into permanent governments. So we should be careful to bake in the P2P path.
Attributes of the shadow network.
But that layer, whatever it is, or becomes, is just a back-end: for the purposes of responding to this API change, the most important thing is that the network (in whatever incarnation) provides a Twitter-compatible API which, crucially, is regulated not by a king, but by a constitution.
Every time a client posts to Twitter, it also posts to the TPAD network. Every time a client reads from Twitter, it also queries the TPAD network. (Deduplication is simple.)
After a while, Twitter will be seen as just the bootstrap loader of the eventual open network. "Twitter, an early proprietary version of the global IM network, fell out of favour due to perceived heavy-handedness in its search for a sustainable commercial model," the history books will read.
Once enough people are using the shadow network, you can fork the protocol, and the Twitter people have to come to the table – they have to attend the IETF meetings where the working group hashes out a compromise between the unruly FLOSS community and the VC-backed billion-dollar startup. (These meetings will be made easier by the fact that the Twitter engineers who attend them are, on some level, secretly sympathetic to the opensource community, having been born from the same DNA. Skype engineers will participate too, but their contributions will be tainted by the fact that Microsoft signs their paychecks.)
How will the TPAD community answer the challenges of commercialization and sustainability? Again being fair to Twitter, from Twitter's point of view the TPADs are freeloaders, parasites, running clients against Twitter's rock-solid service backend only to siphon away advertising dollars that belong to Twitter. Of course Twitter wants to control the presentation layer; whoever is closest to the end-users gets to monetize their eyeballs.
In the interim, the TPADs could negotiate peering arrangements amongst themselves. Third party apps (TPAs) operate in two modes: read and write, or publish and subscribe. Pub/sub architectures have been around for a while, and we can keep accounts based on the termination models from the telco world, imperfect as they are. Or the hosts could just share the load and run it for free until the P2P vision takes off.
I do not see client/server alternatives to Twitter working in the long term. Server models tend to require organizational deployment. Friendica wants to be installed on a server. They've tried to make it as easy as they can, but it's still too hard. I think the eventual model is going to be something like Skype and Bittorrent: P2P nodes masquerading as a desktop client app. All the smarts have to be in something that runs out of the Applications folder, not /usr/local/bin. As we move farther into the mobile generation we will need nodes that can run on smartphones, not desktops.
What does this vision give us? It gives us the Twitter API, with an Internet-scale messaging backend, without the need for the Twitter server farm and the Twitter point of central control, plus federation across multiple organizations and P2P devolution to end-user participation. And that, to me, looks like the beginnings of a truly open, federated, alternative to Twitter.
If the Twitter third-party application developers want to avoid the steamroller, they should build toward this vision.
(All the same arguments, obviously, apply to Facebook application developers. Building a shadow Twitter is easier than building a shadow Facebook, so let's start there.)
This is getting long, so I will end with a braindump: a concentrated lump of advice to the Friendica / Diaspora / Status.net people, the TPAD people, and the rest of the FLOSS messaging community from one of your own, from someone whose open software and open standards have seen worldwide adoption, and who now runs a seed accelerator focused on building next-generation media startups.
My advice is to take a page out of the Lean Startup manual, take messaging app developers as the customer, and aim for an MVP that addresses the Gorilla problem directly. For app developers, that's the biggest pain point today. It's existential. (I think. This hypothesis needs to be tested using a Chapter 6 Interview from Running Lean.) Yes, the hundred and one features that improve the end-user experience are important, but those are mostly sustaining innovations. If you're Status.net or Friendica, use the Kano model to classify each feature request, and rigorously strip out any which are not Must-Be for basic functionality, or that don't serve the goal of freeing the user and the app developer from the central point of control. Blue Ocean Strategy suggests that openness, federation, interoperability, and protocol compatibility with the Twitter API are the key value props here – backburner the other features for now. Compatibility with the API, in particular, allows app developers to justify developing for the shadow network in the name of redundancy. If the Twitter network goes down, don't you want to be able to keep running, albeit in degraded mode? One day it's going to go down not for everyone, but only for you; censorship needs to be routed around; and degraded mode is just another name for a Christensen low-end disruption. Crucially the API can't be your own; you have to be protocol-compatible with Twitter's, so the same libraries work, just with different keys and different endpoints, at least in the beginning. Compatibility is so important that it's one of Everett Rogers's five key attributes: if you don't check all five boxes, your innovation will not be adopted.
Solving spam is left as an exercise for the reader, though solutions like Akismet should transfer.
Bibliography
This essay owes a debt to Neal Stephenson's essay In the beginning was the command line (available online), to Tom Standage's The Victorian Internet, and most of all to Tim Wu's The Master Switch: the Rise and Fall of Information Empires.
Date: 2012-09-14 00:18:59 SGT
Author: Wong Meng Weng
Org version 7.8.11 with Emacs version 23
Strategy Letter to the Twitter Third-Party Ecosystem
The protocol pendulum is about to swing!
This essay explains the history of the protocol pendulum and suggests to the Twitter ecosystem what they could do about it, in the six months between now and March 2013.
September 8, 2012: Twitter's Power Grab
Sarah Mitroff of Wired reports that Twitter has decided to consolidate power. Its API is changing, putting third-party clients at risk. (She mistakenly names TweetDeck as a third-party client; they were acquired by Twitter, so they're safe. But the fact that they dropped LinkedIn updates after the acquisition is telling.)
If I were Nick Carr, I would see this as one of the risks of digital sharecropping.
If I were Geoffrey Moore, I would see this as a power struggle between a gorilla and a bunch of chimps.
If I were a naturalist, I would see Twitter as a shark and its third-party clients as remoras.
Now the shark has just decided that its commensals are really parasites, and wants to get rid of them.
Lessons from History
All of this has happened before and will happen again.
Geeks of a certain age will remember Watson: a fine third-party extension to Mac OS. It made a respectable shareware living, complementing the base OS with features so useful it won an Apple Design Award the year it was launched. The very next year, Apple decided that those features really did belong in the OS, and with its release of Sherlock 3, squashed Watson flat as a penny under a steamroller. With friends like that, who needs flattery?
That was ten years ago.
Let me explain my perspective. Paul Graham coined the phrase "the periodic table of protocols." After Mendeleev, chemists characterized the known elements and discovered new ones. Similarly, there exists a small fraternity of Internet architects and engineers who maintain messaging systems and devise new media. For a time, I was one of them.
I first got on the Internet in 1992. I have watched the pendulum swing time and time again: between open and closed, between free and proprietary, between centralized and federated, between the walled garden and the bazaar.
Tim Wu's The Master Switch: the Rise and Fall of Information Empires tells the story of how the pendulum has swung back and forth for every medium we know today, from film to radio to TV.
Its lessons are important for new media. Email is a medium too; so are online video, instant messaging, and Twitter. The periodic table of protocols has many squares, and each square has its isotopes and allotropes.
Internet Media: Open versus Closed
Some media are open. Some are closed. Email is fundamentally open. Even though most people have an email address at gmail.com, hotmail.com, or yahoo.com, any person can register a new domain and get an email address with their name on the left of the @ sign, and their organization on the right. I, for example, am meng...@pobox.com, which is an email hosting service I co-founded almost 20 years ago.
In the world of Twitter my address is just @mengwong. In the language of email, it would have been meng...@twitter.com. But Twitter has gone and done a clever thing – they assumed the entire namespace in a move as deft as any magician's sleight of hand.
By allowing my handle to be just @mengwong, Twitter (the instant messaging concept) has been co-opted by Twitter (the company), which attached an invisible, implicit "@twitter.com" to every Twitter handle, instantly arrogating to itself the sort of power that in other industries people like Ted Turner have to work entire lifetimes to amass. And they didn't even mean for it to turn out that way – it just happened. @ messaging was a user-led innovation, not a Twitter design.
Twitter doesn't have to be a monopoly. Take online video. It looks like an oligopoly between YouTube and Vimeo and Ustream and Justin.tv and a dozen other services each serving their own niche. But if you really wanted, you could be free of all of those service, and offer video directly from your own broadband connection on BitTorrent.
So there is a spectrum that runs from open-source / open-standard / fully-federated, to a wholly proprietary walled garden. Every medium can be located somewhere on that spectrum.
What does it mean that email is federated and open? In theory anybody could establish an email server, a first-class entity in the world of ports 25 and 587, ranking equally with Gmail and Hotmail. In practice most people hand the job of running the email server to somebody like Gmail, either by registering for an email address @gmail.com, or by registering their domain and then hosting that domain with gmail.
What about the front-end? In theory anybody could write their own email client: Outlook and Mac Mail are just two "MUA"s among many. (MUA, or Mail User Agent, is the technical term for an email client.) In practice, most people just use whatever software happens to be on their computer, or they use a web interface like Gmail's.
So Gmail has produced an end-to-end, vertically integrated, email offering built on top of open standards: a client (www.gmail.com) which speaks open-standard HTTP and HTML, and an inbound server to receive mail (smtp.gmail.com) which speaks open-standard SMTP.
If you don't like Gmail's web interface, you don't have to use it. Google offers open-standard POP and IMAP endpoints for your native client to talk to.
If you don't like the @gmail.com domain, you can register your own, and still have Google run the domain in the back end.
And if you don't want to use Gmail at all, you can run your own, free, opensource email server software – sendmail, qmail, postfix – and run your own opensource email client – Thunderbird – or even write your own, after reading the standards yourself. The RFCs are out there, free to download.
Same with the web. Anyone can bring up a web server; in fact, every Apple laptop comes with a free one built in. And Firefox is opensource.
Is Twitter like email and the web? No. You couldn't bring up your own Twitter server if you wanted to. All the third-party clients talk to Twitter using its API. Take your iPhone (if you have one) out of your pocket and go into Settings: you can set up any email service you want, with a username, password, and server, but when it comes to Twitter, you get to enter the username and password that you use for, well, Twitter. There is no choice for server.
That, in a nutshell, is the difference between open and proprietary.
XMPP offers an interesting lesson: where instant messaging used to be closed, XMPP turned it toward openness. And "don't be evil" Google adopted it for Google Talk. Where XMPP is synchronous and private, Twitter is asynchronous and public. (The periodic table of protocols is built on attributes like these. I could enumerate and analyze every protocol and medium, but I will spare you.)
Today, the closest thing to an opensource version of Twitter is status.net, previously laconi.ca, now identi.ca.
Similarly, Diaspora and Friendica are opensource alternatives to Facebook.
These alternatives haven't had much traction – yet. That could be about to change.
A Magna Carta Moment for Twitter
Twitter announced its API change last Wednesday, sending shockwaves through the ecosystem of third-party apps. Like Watson relative to Mac OS, all these apps depend on Twitter. The third-party app developers (who I will call TPADs for short) are like planets revolving around the sun. In Geoffrey Moore's language, they are chimpanzes next to a gorilla.
(Want to see what happens when the gorilla yanks the chimps' chain? See Twitterlocal's home page. )
Some people might not have much sympathy for the chimpanzees. It's a free market; the Internet is a libertarian paradise; and if Twitter wins, why, so be it: more power to them.
But not everybody agrees. The TPADs, of course, disagree. And some strain of public policy tracing its roots to the Sherman Antitrust Act of 1890 believes that monopolies need to be curbed.
But I don't see the US DoJ getting involved in a protocol skirmish anytime soon. Microsoft was the last big target of an antitrust action: that was ten years ago, and look how that turned out.
Besides, the Department of Justice is a blunt instrument. 21st century problems deserve 21st century solutions.
We can all understand Twitter's commercial motivations for their API change. They want to make money; they want to lock out what they perceive as the competition, and when the MBAs at Twitter were brainstorming solutions to this "problem", they must have stopped at the first idea: iron fist of control.
To be fair to Twitter, it's not easy to build reliable Internet-scale messaging infrastructure. Millions of dollars have gone into building Twitter, and it's only fair that the company should make money and the investors should see a return.
But at what cost, and at whose expense? What Apple did to Watson was widely regarded as a rotten move, and I want to believe that whatever deities watch over the evolution of the Internet look on that sort of monopolistic power play with disfavour. Let this essay be an offering to them.
I think there are better ways to play the game. I think this is a golden opportunity for the Internet polity in general, and the Twitter ecosystem in particular, to push the pendulum toward openness. Everybody wins in the long run – the TPADs, the public, and even Twitter.
If the Internet were a country, the third party app developers would rise up and argue that The Government Should Do Something. But the Internet is not a country – there is no tax revenue, and there is no democratically representative body charged with the allocation of that tax revenue toward public goods.
On some level this situation can be read as a governance problem. The IETF is kind of like a legislative body, but the ICANN isn't even close to being an executive branch. Who pays for public goods? The opensource folks do, in kind.
The state of the Internet isn't at the point where we can even talk about branches of government. We're still a few centuries behind.
Back in the year 1215, a handful of individuals found themselves in a position not dissimilar from Twitter's TPADs today. Playing the role of Twitter was King John, and playing the role of the app developers were his barons.
It could be time for a Magna Carta moment: a starting point on the road that leads from a monarchy to a republic.
What can the barons, the TPADs, do?
Let me lay out one possible future for the Twitter ecosystem.
A Possible Future
The Third Party Application Developers, the Status.nets, and the Friendicas of the world should take Twitter's great advantage – the unitary namespace – and use it against them. They should develop a shadow network that embraces and extends Twitter's.
They should make it free and open, but also monetizable. Advertising is one possible revenue model but not the only one.
They should build toward a level playing field, where each player can monetize in its own way, and share in the riches of all the others. This is an example of an industry regulating itself – not as a monarchy but as a republic. Monarchies centralize power. Republics decentralize power.
Why shouldn't every third-party Twitter app, every Twitter client, also be a peer and a server? At the end of the day, Twitter is merely a keyword-oriented asynchronous message-passing directed acyclic graph. A DHT (Distributed Hash Table) is an ideal P2P architecture for implementing a keyword-oriented asynchronous message-passing DAG.
In the long term, the P2P DHT model makes everything cheaper. Maybe Twitter's massive back-end server farm isn't actually necessary. Skype and Bittorrent wouldn't exist if not for P2P technologies. Why not bring that architecture to Twitter? As a matter of fact, I'd be surprised if some engineering team within Skype hasn't already developed a Twitter-smasher, only to have it sidelined due to political intrigue at the highest levels of Microsoft's palace hierarchy.
There are already open alternatives to Twitter just waiting for their turn. Status.net/identi.ca, Friendica, Diaspora, and other champions of the Open Stack are natural candidates for Twitter TPADs to interoperate with.
In the long term I would like to see a P2P DHT network of intercommunicating peers, serving a distributed social network, within which the Twitter medium is represented. As an interim measure, as a way to get there, the TPADs could bring up the mother of all IRC networks: big enough to scale to 10 million users, federated across all the TPADs, and operated according to the same sorts of peering agreements that the Internet and today's IRC networks run on.
(When Twitter first came out, I laughed and said: "they've reinvented IRC!" Most people had no idea what I was talking about. They had never used IRC. But it just goes to show that every generation thinks it is inventing sex for the first time.)
The interim network doesn't have to be IRC – it could run on top of XMPP or Status.net or Friendica. And interim networks have a way of turning into the permanent networks, just as interim administrations have a way of turning into permanent governments. So we should be careful to bake in the P2P path.
Attributes of the shadow network.
But that layer, whatever it is, or becomes, is just a back-end: for the purposes of responding to this API change, the most important thing is that the network (in whatever incarnation) provides a Twitter-compatible API which, crucially, is regulated not by a king, but by a constitution.
Every time a client posts to Twitter, it also posts to the TPAD network. Every time a client reads from Twitter, it also queries the TPAD network. (Deduplication is simple.)
After a while, Twitter will be seen as just the bootstrap loader of the eventual open network. "Twitter, an early proprietary version of the global IM network, fell out of favour due to perceived heavy-handedness in its search for a sustainable commercial model," the history books will read.
Once enough people are using the shadow network, you can fork the protocol, and the Twitter people have to come to the table – they have to attend the IETF meetings where the working group hashes out a compromise between the unruly FLOSS community and the VC-backed billion-dollar startup. (These meetings will be made easier by the fact that the Twitter engineers who attend them are, on some level, secretly sympathetic to the opensource community, having been born from the same DNA. Skype engineers will participate too, but their contributions will be tainted by the fact that Microsoft signs their paychecks.)
How will the TPAD community answer the challenges of commercialization and sustainability? Again being fair to Twitter, from Twitter's point of view the TPADs are freeloaders, parasites, running clients against Twitter's rock-solid service backend only to siphon away advertising dollars that belong to Twitter. Of course Twitter wants to control the presentation layer; whoever is closest to the end-users gets to monetize their eyeballs.
In the interim, the TPADs could negotiate peering arrangements amongst themselves. Third party apps (TPAs) operate in two modes: read and write, or publish and subscribe. Pub/sub architectures have been around for a while, and we can keep accounts based on the termination models from the telco world, imperfect as they are. Or the hosts could just share the load and run it for free until the P2P vision takes off.
I do not see client/server alternatives to Twitter working in the long term. Server models tend to require organizational deployment. Friendica wants to be installed on a server. They've tried to make it as easy as they can, but it's still too hard. I think the eventual model is going to be something like Skype and Bittorrent: P2P nodes masquerading as a desktop client app. All the smarts have to be in something that runs out of the Applications folder, not /usr/local/bin. As we move farther into the mobile generation we will need nodes that can run on smartphones, not desktops.
What does this vision give us? It gives us the Twitter API, with an Internet-scale messaging backend, without the need for the Twitter server farm and the Twitter point of central control, plus federation across multiple organizations and P2P devolution to end-user participation. And that, to me, looks like the beginnings of a truly open, federated, alternative to Twitter.
If the Twitter third-party application developers want to avoid the steamroller, they should build toward this vision.
(All the same arguments, obviously, apply to Facebook application developers. Building a shadow Twitter is easier than building a shadow Facebook, so let's start there.)
This is getting long, so I will end with a braindump: a concentrated lump of advice to the Friendica / Diaspora / Status.net people, the TPAD people, and the rest of the FLOSS messaging community from one of your own, from someone whose open software and open standards have seen worldwide adoption, and who now runs a seed accelerator focused on building next-generation media startups.
My advice is to take a page out of the Lean Startup manual, take messaging app developers as the customer, and aim for an MVP that addresses the Gorilla problem directly. For app developers, that's the biggest pain point today. It's existential. (I think. This hypothesis needs to be tested using a Chapter 6 Interview from Running Lean.) Yes, the hundred and one features that improve the end-user experience are important, but those are mostly sustaining innovations. If you're Status.net or Friendica, use the Kano model to classify each feature request, and rigorously strip out any which are not Must-Be for basic functionality, or that don't serve the goal of freeing the user and the app developer from the central point of control. Blue Ocean Strategy suggests that openness, federation, interoperability, and protocol compatibility with the Twitter API are the key value props here – backburner the other features for now. Compatibility with the API, in particular, allows app developers to justify developing for the shadow network in the name of redundancy. If the Twitter network goes down, don't you want to be able to keep running, albeit in degraded mode? One day it's going to go down not for everyone, but only for you; censorship needs to be routed around; and degraded mode is just another name for a Christensen low-end disruption. Crucially the API can't be your own; you have to be protocol-compatible with Twitter's, so the same libraries work, just with different keys and different endpoints, at least in the beginning. Compatibility is so important that it's one of Everett Rogers's five key attributes: if you don't check all five boxes, your innovation will not be adopted.
Solving spam is left as an exercise for the reader, though solutions like Akismet should transfer.
Bibliography
This essay owes a debt to Neal Stephenson's essay In the beginning was the command line (available online), to Tom Standage's The Victorian Internet, and most of all to Tim Wu's The Master Switch: the Rise and Fall of Information Empires.
Date: 2012-09-14 00:18:59 SGT
Author: Wong Meng Weng
Org version 7.8.11 with Emacs version 23
Rodrigo Martinez
Brings back so many memories like benchmarking which was faster: Ymodem-G with CCITT V.42bis enabled or disabling V.42bis (via AT command set) altogether and compression the file with PKZIP and also with the Japanese LHA. PKZIP vs LHA was a whole separate discussion. Everyone was trying to squeeze the last bit of juice out of our 2400bps modems. Modems kept getting faster and faster, ZModem MobyTurbo rocked so LHA vs ZIP became irrelevant.
IRC, qpopper, etc…Sweet!
The early nineties are a "school" which is priceless.
Meng, thanks for bringing back the "foundational wisdom" (just made this up) in such an elegant reading.
Keep it coming!
Best,
Rod
Bring back so many memories…Xmodem, Ymodem, Zmodem
Rowan Simpson
Zooko Wilcox-O'Hearn
Greetings, Open Froggers.
First of all, I'm not sure why you thought of me, but I'm glad you
did, because I've been thinking of contacting you to ask for advice
about my startup -- https://LeastAuthority.com .
Secondly, while I am strongly in favor of the federated alternative to
twitter for reasons of the social good, I don't see why the pendulum
is going to swing that way just because of the fate of the TPADs. Do
the TPADs control a lot of a money and power? And even if they have
enough collectively, will they be unable to exert their money and
power in a synchronized way? (It could be a tragedy-of-the-commons
problem, where the TPADs as a group would benefit from launching this
new ecosystem, but each individual TPAD is better off to spend its
resources scrambling for scraps from the current system.)
Thirdly, I think this is what identi.ca/statusnet tried to do, and I
think that it has basically failed on business grounds (although it
partially works on technical grounds -- I use https://identi.ca to
post to twitter but I use https://twitter.com to read twitter). Maybe
you should ask Evan Prodromou his opinion. He is a smart and
expressive guy. He would probably enjoy your essay. I could introduce
you.
Fourthly, I think you were right to put your finger on the namespace
as the "natural monopoly", the choke-point, but also that this may be
changing -- in the future maybe we'll learn how to make a name into a
sort of native, atomic resource of cyberspace. That's what Namecoin
(of Bitcoin) does: makes names unseizable, without requiring any
trusted third party to be the incorruptible steward of the names.
Regards,
Zooko
Martin Bähr
> So between lunch and dinner today I spewed out about 3000 words on the
> "sky is falling" change to the Twitter API, particularly in response
> to the Wired piece.
style nitpicks:
you seem to explain twice how email works.
you mention two or three times how XMPP or Status.net or Friendica etc
are alternatives.
and then you explain that Friendicas server model wouldn't work.
backburner is a verb?
Sebastiaan Deckers
Contrary to what you implied, the IETF is not some romanticised "unruly FLOSS community." At IETF meetings discussing XMPP you're more likely to meet Real Engineers from Cisco or DoD/MoD contractor, and not startup brogrammers or FOSS hackers.
Paul Gallagher
Secondly, while I am strongly in favor of the federated alternative to
twitter for reasons of the social good, I don't see why the pendulum
is going to swing that way just because of the fate of the TPADs.
May be useful to look at the situation through the lens of the "Innovator's Dilemma". Here's my rough take:
Twitter was originally the classic example of an upstart disrupting an industry:
- it took simple, existing technology
- gave a mass audience a new way to communicate
- and in the process, left old IM, IRC, and telco SMS services looking decidedly flat-footed.
- millions of customers (who don't pay anything) but get all the value of information sharing in a public forum
- lots of TPADs, who (hope) to build a business on the Twitter infrastructure by providing incremental value to users
- marketeers, news and PR companies who use Twitter to drive revenue
- ________ (the blank space Twitter is trying to fill in: who pays the music man?)
How can a TPAD break away from this dilemma? The model would suggest they need to find a way to leverage the Twitter infrastructure in a way that fundamentally changes the value network. Unfortunately I can't think of any real examples (perhaps something like the experiments to crowd-sourced financial stock tipping??) but there are real challenges here because you will always be beholden to the platform provider: and since your value network will not coincide with Twitter's idea of a value network, there will be conflict (which you will lose of course).
This also perhaps explains why platform alternatives (like identica) have failed to take off, since they are really not yet promising anything much different from the value network perspective (at least from the perspective of the main user audience). It is also why I am quite sceptical of app.net's chances of success.
So if we take the Innovator's Dilemma quite literally, we can say:
- it is not enough to just reinvent the technology. Twitter will not be dethroned simply by technological innovation (in fact, it will probably just make them stronger)
- The new wave of innovators that might dethrone Twitter need instead to discover/invent new value networks
What might that look like? If I knew the answer, I probably wouldn't be sitting here posting notes on a mailing list;-)
But if we look at app.net as a candidate, they are basically pitching "we promise to be everything you thought Twitter was or should be" (ad-free with an official API). I think that's not enough, since I suspect the bulk of users would say:
- ad-free: yes, most of the time. But I actually don't mind getting *some* ads
- official API: do I care? I thought Twitter has one?
But these are concepts that probably sell well to TPADs. In a way it seems app.net have gone down the suggested path:
> take messaging app developers as the customer, and aim for an MVP that addresses the Gorilla problem directly
The catch is of course that if you are not appealing directly to end-users, then success is totally in the hands of the TPADs. It needs a TPAD to create something that is nothing like Twitter (new value network) running on app.net, which will bring in the users.
Sorry, Meng. I strayed from simply providing comments on the article you asked for. Maybe the thoughts help, if not then TLDR!
PS: I think there is a somewhat orthogonal discussion to be had concerning the part of the TPAD market that Twitter could chop off at it's own peril: those guys who provide aggregation across many social networks. Probably the biggest pain for social network users is that they have to choose (which to use). On the one hand, social network providers want you to choose too (theirs). But you can't fix this paradox by building yet another infrastructure to choose .. unless you can kill off all the others. So it is actually in the established social network's best interest to support some degree if interoperability in order to defend against being killed by an upstart network. So I would not be surprised to see a Google/Facebook/Twitter consortium gradually agree to "just enough" interoperability to keep the likes of app.net in their place. Would the Justice Department have fun with that? Oh yes.
Patrick Haller
> clients as remoras.
>
> Now the shark has just decided that its commensals are really parasites,
> and wants to get rid of them.
Twitter just stopped twitter-related consumer-visible innovation.
Which means Twitter just became AOL.
For a time, people kept paying for their AOL accounts because they
thought they would lose their AIM accounts. But AOL didn't innovate, AIM
accounts lost relative value, and the Internet routed around AOL....
To kill Twitter earlier than evan-tual obsolescence, why not open an RFS
for twitter-clients while building a bot-net Twitter scraper to
replicate the Data API? Twitter doesn't own the tweets....
Meng Wong
>
> To kill Twitter earlier than evan-tual obsolescence, why not open an RFS
> for twitter-clients while building a bot-net Twitter scraper to
> replicate the Data API? Twitter doesn't own the tweets....
>
For anybody who's just tuned in: an RFS is a Request for Startups. The concept was pioneered by YC: http://ycombinator.com/rfs.html
The argument for an RFS:
Our investors and mentors have tons of business experience, entrepreneurial ability, and cash.
We found that they lie awake at night thinking of new business ventures that would be totally awesome, but they're just too old or too busy to do them.
So JFDI will help them write up their ideas in the form of an RFS and recruit teams that match.
That way, our investors get to mentor the teams and see their ideas come true!
Already I have RFSes planned in the areas of:
- next generation email
- next generation open Twitter API backend for app developers
- disrupting excel (http://stoic.com/ might have this covered)
- life2cloud
- startup in a box: incorporation, due diligence, vesting schedule, ESOP plan, term sheets
- menu redesign as a service
Meng Wong
Sorry, Meng. I strayed from simply providing comments on the article you asked for. Maybe the thoughts help, if not then TLDR!
Josh Russell
I'm trying to get together a guest post for TechCrunch, but it'll
likely be more about founder life, investor appetites, hiring, etc..
rather than talk about the Twitter API changes.
Did you happen to catch Nova's blog post? I think he's on the money,
so to speak...
http://www.novaspivack.com/uncategorized/the-twitter-api-insanity-what-everyone-seems-to-be-missing
–Josh
Meng WONG
Benjamin Scherrey
--
You received this message because you are subscribed to the Google Groups "OpenFrog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openfrog+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
Visit this group at http://groups.google.com/group/openfrog.
For more options, visit https://groups.google.com/d/optout.