Disclaimer: the thoughts expressed here are my own and do not necessarily reflect the opinions of others who participated in the conversation that inspired this post.
Here are some more thoughts about Echo:
- The success or failure of software is measured by the number of people who benefit from its use.
- Today’s weblog software is providing a lot of benefit to a lot of people. As that number grows, the fraction that cares about the backend details will diminish to rounding error.
- Many (most?) of the Roadmap signers are people who specifically care about the backend details, i.e. programmers. The best programmers have a keen sense of what is useful to people, but most don’t. [We tend focus on how much work we will have to do, or what is possible, whether or not it is useful, or our own personal notion of source code beauty. I.e. things that are invisible to 99.99% of the world.]
- As best I can tell, “today’s backend provides no value” is not among the reasons why Echo appeared.
- There is definitely an element of “today’s backend is not providing enough value, a better backend is needed”. That gets us into cost/benefit analysis.
- Immediate benefit: Echo is a release valve. People who feel that they haven’t had a voice now have a voice. For a while, there will be less grumbling and subsequently less bad PR. The grumbling will return when it becomes apparent that lots of people have voices and their voices want different things. But maybe this time it will be more effectively managed.
- Potential benefit: Echo delivers. A spec is published, tools are built, the world changes for the better.
- Cost: “Let’s hold off on implementing our feed/application/tool. There are too many competing specs. Everyone’s going to be doing Echo anyway. Let’s wait for Echo.”
So what can we conclude? Programmer grumbling is unfortunate but it is no match for the roar of happy users. If Echo does not deliver something substantially better than what came before, we will have a net loss. Will Echo deliver? I sure hope so.