The IndieWeb is a global community of hackers, tinkerers, and makers that are creating communication protocols, libraries, and software to power a decentralized social web. The IndieWeb focusses heavily on “dogfooding” or using these experimental new technologies in your daily web activity
a people-focused alternative to the ‘corporate web’.
Your content is yours
When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.
You are better connected
Your articles and status messages can go to all services, not just one, allowing you to engage with everyone. Even replies and likes on other services can come back to your site so they’re all in one place.
You are in control
You can post anything you want, in any format you want, with no one monitoring you. In addition, you share simple readable links such as example.com/ideas These links are permanent and will always work.
Key principles of building on the indie web, numbered for reference, not necessarily for any kind of priority.
Own your data.
Use visible data for humans first, machines second. See also DRY.
Build tools for yourself, not for all of your friends. It's extremely hard to fight Metcalfe's law: you won't be able to convince all your friends to join the independent web. But if you build something that satisfies your own needs, but is backwards compatible for people who haven't joined in (say, by practicing POSSE), the time and effort you've spent building your own tools isn't wasted just because others haven't joined in yet.
Eat your own dogfood. Whatever you build should be for yourself. If you aren't depending on it, why should anybody else? We call that selfdogfooding. More importantly, build the indieweb around your needs. If you design tools for some hypothetical user, they may not actually exist; if you build tools for yourself, you actually do exist. selfdogfooding is also a form of "proof of work" to help focus on productive interactions.
Document your stuff. You've built a place to speak your mind, use it to document your processes, ideas, designs and code. At least document it for your future self.
Open source your stuff! You don't have to, of course, but if you like the existence of the indie web, making your code open source means other people can get on the indie web quicker and easier.
UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols & formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
Build platform agnostic platforms. The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform. The more your code is modular, the greater the chance that at least some of it can and will be re-used, improved, which you can then reincorporate.
Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn't require us to destroy everything we've done every few years in the name of progress.
Plurality. With IndieWebCamp we've specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
Have fun. Remember that GeoCities page you built back in the mid-90s? The one with the Java applets, garish green background and seventeen animated GIFs? It may have been ugly, badly coded and sucky, but it was fun, damnit. Keep the web weird and interesting.
Amber Case, Kevin Marks, Amy Guy, Dan Gillmor