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
To set some context for feedback, were you following any particular development methodology for this project, eg Lean Innovation?
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.
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?
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.
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?
So Meng and I have different views on this.
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.
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.
(yep I lurk here!)
If you want to ask questions I'll be as open and frank as possible!
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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:
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!
--
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.