*I like principles. Not that I obey them or anything, I just like them.
http://indiewebcamp.com/principles
Principles
Some rough principles of building on the indie web...
▪ 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? 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.
▪ 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. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest most minimal protocols sufficient to support that UX, and nothing more.
▪ 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.
▪ Build for the long web. If human society is are 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.
▪ 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.
Background
With IndieWebCamp we've specifically chosen to encourage and embrace a diversity of approaches/implementations.
One of the key things we recognize with IndieWebCamp is that no one implementation is likely to be the answer.
We're much more likely to advance the state of the art by encouraging everyone to build what works for them, and then figure out how to interoperate between different coding/implementation approaches. This is what makes IndieWebCamp different (more inclusive) than all other such "open source" efforts out there.
Multiple implementation efforts help to simultaneously explore different parts of the indieweb problem space as we're all choosing to focus on building the particular aspects of what's important in an indie web site for ourselves. Additionally, multiple approaches to the same problems in essence A/B(/C/D/...) test different approaches simultaneously, each of which can then learn from and evolve in response to the others.
This parallel diversity both produces better indie web solutions faster, and allows for the incorporation of new approaches to address new problems, adapting as the needs of an indie web site change over time.
Discussion
▪ There seems to be an unwritten principle of focusing on UX that I've encountered multiple times while participating in the indieweb community. A recent example where it was cited is this. Should we make it explicit? (see also [1]) -Www.sandeep.io 18:54, 7 July 2013 (PDT)
▪ Added explicit principle above about UX/design. -
Tantek 13:40, 24 August 2013 (PDT)
See Also
▪ why
▪ antipatterns
