In a post on branch, Brian Oberkirch asks,
Why are silos beating the light out of an open social Web? with some insightful points by Dave McClure. The biggest change I've seen in this debate over the years is a shift from "versus" to "leverage", and a recognition of the strengths of different approaches and in having a diversity of approaches.
First, let's dissect Dave's points one at a time:
"1) the problems we were interested in were only relevant to geeks"
This is a fair criticism of a lot of open social web work, though the seemingly obvious response was ironically worse. When open social web geeks attempted to prematurely design their technologies/solutions to attempt to work "for everyone" or for your (insert less tech-savvy family-member stereotype here), they ended up creating solutions that no one wanted for themselves, not even the geeks on their own websites. WebFinger is a prime example here.
The answer is not to not "only [be] relevant to geeks", but rather, reframe it as a positive, and be relevant to yourself. That is, design, architect, create, and build for yourself first, others second. If you're not willing to run your design/code on your own site, for your primary identity on the web, day-in and day-out, why should anyone else? If you started something that way but no longer embrace it as such, start over. Go Selfdogfood or go home.
Copy, simplify, personalize UX
"2) our UX sucked and no real people wanted to use them"
UX is hard. Design is hard. Both are so hard that even silos screw up sometimes (often?) and regress in their interfaces. Look at how cluttered even Twitter has become, as compared to their initial simple input box on top of a stream of posts interface.
Another side-effect of selfdogfooding is that it makes you self-conscious about the look and usability of what you're creating, because you're putting it on your own primary identity on the web! It's a constant emotional feedback loop that forces you to keep improving it. If all you're working on is an open source project that you expect other people to download and use, then all the design and UX problems are one level removed, they're a to-do list instead of a personal impression problem and are less likely to be fixed.
Want a decent UX? Steal from the best and then simplify. All the silos are pressured to clutter and corrupt their UX with ads, "stickiness", "engagement", and all kinds of other garbage in a never-ending hamster-wheel chase of ever more page views. You don't have that problem. Take their best stuff and make it simpler, more elegant by cutting out all that crap. And then iterate.
Business, web architecture, why not both?
Dave's last paraphrased point:
"3) we weren't working on the business drivers & instead put our faith in the architecture of the Web as a thing that should and would seek its own level in terms of creating and parsing out value."
Too bad about the web. If only Tim Berners-Lee had focused on the "business drivers", maybe HTML, HTTP, and URL would have succeeded.
But seriously, the point is not so much about putting "faith in the architecture of the Web as a thing" (though there's plenty of examples demonstrating the greater robustness/longevity of "webby"/decentralized architectures over centralized ones), but more about focusing on solving real problems for people, starting with yourself, and connecting with those you care about.
People pay hundreds of dollars annually to providers to own their own cell phone numbers which they can use to contact others with phone numbers. They can "port" their numbers from one provider to another.
Some (new?) ISP/domain/web host will eventually figure out a way to make it just as easy to sign-up for a domain and web hosting as it is to get a cell phone number, and with the right software, just as (more) useful, as well as portable to other hosting providers. A portable "one-click indieweb setup" as it were.
And why not both? How about a "phone" that would let you "txt" someone via their domain name? All you would need would be an open web based device, an indieweb messaging protocol & library, and a simple webapp to do so.
I'd much rather say "just txt tantek.com" than "txt (10-number-sequence)". There are even hints at attempts at backward compatibility with solutions like Apple's iMessage, which albeit limited to iOS and latest OSX devices, still let me say "just iMessage tantek at tantek dot com" and receive it on my iPod, without having to pay a cell provider for the service. I am not a number, I am my domain name.
Leverage the silos
"Fast forward & almost everyone works at one of the silos"
Some are certainly trapped behind gilded walls, lost in silo-specific UX and product design. Some are just tired of protocols and instead are getting paid to learn how to make user-useful interfaces. Others are (were) even trying to change things from the inside. Whatever the reason, it's clear there's more to be gained by figuring out how to leverage silos, instead of leaving them. Individuals who work at Google, Twitter, and other silo hosts have actively and positively contributed to IndieWebCamp every year, often with new and helpfully broadening perspectives.
The evolution of indieweb identity
"ID & social graph is dominated by them [the silos]"
No doubt there. Facebook "Connect" is not merely an option but sometimes required (Massive Health, Lyft). OpenID proponent Simon Willison wrote about why he used Twitter sign-in instead of OpenID for his own startup Lanyrd (I'd link to his post but his domain simonwillison.net appears to be down).
Though new adoptions of OpenID appear to be waning, it's still in use in plenty of places, sometimes even required, e.g. to submit a proposal for the Open Source Bridge conference (which you should and can do until ).
And lastly, there's Web Sign-in (based on RelMeAuth) which leverages various silos' OAuth support to provide independent domain based identity. The best example of Web Sign-in is the nice service-based version IndieAuth which the IndieWebCamp.com wiki and several indieweb sites support for signing-in.
Try IndieAuth with your domain name and see how it works.
Feeds are dying, long live feed semantics
"feeds themselves feel like they might be failing"
Indeed. Yesterday's announcement that Google is retiring Google Reader adds weight to that. Although it's possible that Google culturally/hierarchically doesn't care about building services on the open web (aside from search), preferring instead to funnel everyone (via search, Gmail, YouTube) into their G+ silo.
Just design/code/build/ship/share it
"Should we try to put these ideas back into play? Admit that we framed it incorrectly? Or is the outlook better than what I have described?"
Many of the "open social web" ideas have been either misframed or misprioritized, e.g. federation rather than people, or designing for every-person something you won't even run for yourself.
If we take the more positively framed approach, focusing on building stuff you'll use every day yourself, and focusing on connecting with each other, we end up with a different set of diverse building blocks, some of which look a lot like old building blocks, but repurposed to be useful to us immediately, rather than useful someday to someone, and taking a diversity of approaches, rather than advocating a monoculture around any one particular open source project.
Join the indieweb
Finally, if you've gotten this far, you should join the rest of us doing so:
- Immediately, on IRC: #indiewebcamp on Freenode.
- In person, at IndieWebCamp 2013, - in Portland, Oregon