From IndieWeb

developer-principles are an in-progress Brainstorm of the IndieWeb Principles intended for a developer audience.

This is an in-progress Brainstorm of the principles intended for a developer audience

Since the principles largely started out at as developer principles, which still make sense for developers, as we rewrite/reframe the principles to be more broadly applicable, user-friendly, accessible, we should keep (and maintain) the versions that are intended for developers. To start with, most of these are merely a copy/paste of the existing principles since many were already more applicable to developers. โ€” Tantek ร‡elik

Including also the Own your identity brainstorm as well.

Key Principles

  1. โœŠ Own your identity.
  2. ๐Ÿ—„ Own your data.
  3. ๐Ÿ” Use & publish visible data for humans first, machines second. See also DRY.
  4. ๐Ÿ’ช Make what you need. Make tools, templates, etc. for yourself first, not for all of your friends or โ€everyoneโ€œ. If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist. Make something that satisfies your needs (also known as scratch your own itch), and is compatible for others, e.g. by practicing POSSE, you benefit immediately, while staying connected to friends, without having to convince anyone. If and when others join the indieweb, you all benefit.
  5. ๐Ÿ˜‹ Use what you make! Whatever you build you should actively use. If you aren't depending on it, why should anybody else? We also use the metaphor eat what you cook for this principle. Personal use helps you see both problems and areas for improvement more quickly, and thus focus your efforts on building the indieweb around actual needs and consistently solving immediate real world problems, instead of spending lots of time solving what may be theoretical problems.
  6. ๐Ÿ““ Document your stuff. You've made a place to speak your mind, use it to document your processes, ideas, designs and code. Help others benefit from your journey, including your future self!
  7. ๐Ÿ’ž 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.
  8. ๐Ÿ“ 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.
  9. ๐ŸŒ Modularity. 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. Modularity increases the chance that at least some of it can and will be re-used, improved, which you can then reincorporate. AKA building-blocks. AKA "small pieces loosely joined".
  10. ๐Ÿ—ฟ 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. Consider making things on the web that are designed to last.
  11. โœจ 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.
  12. ๐ŸŽ‰ Above all, Have fun. When the web took off in the 90's people began designing personal sites with tools such as GeoCities. These spaces had Java applets, garish green background and seventeen animated GIFs. It may have been ugly and badly coded but it was fun. Keep the web weird and interesting.

Consolidated developer principles

Thinking about having a discrete set of principles that can sit below and support the broader principles, Paul Robert Lloyd pulled out those from the above that appeared aimed at developers and came up with the following list.

Each of the headings includes โ€˜makeโ€™ to help clarify who the principles are aimed at. It also means they work better together as a cohesive set. The suggested emoji are also food related to underline the idea of making.

They are ordered by the priority youโ€™d follow when building something new (you canโ€™t document or open source something that you havenโ€™t built yet, for example).

๐Ÿฉ Make it user-centred
Usability is more important than protocols, formats, data models, schema etc. Start with user needs, and figure out how to build the simplest, easiest and most minimal solution that can address them.
๐Ÿฅช Make what you need
Donโ€™t design for a hypothetical user as they may not exist. Make something that satisfies your own needs, first. Also known as scratch your own itch.
๐Ÿฝ๏ธ Use what you make
Personal use can help you uncover problems and areas for improvement more quickly. Focus on solving real problems instead of theoretical ones. Also known as eat what you cook.
๐Ÿญ Make it your way
We can innovate faster if everyone builds what works for them and we figure out how to interoperate between different approaches later. Having a plurality of projects makes the indie web more inclusive than other open source efforts.
๐ŸŒฎ Make it open
Building software collectively and in the open instead of privately and in the abstract means it is more likely to be used. Making your code open source means other people can build upon what youโ€™ve made.
๐Ÿฑ Make it modular
The more modular your code is, the less dependent youโ€™ll be on a particular device, interface, API, programming language, storage model or platform. Modularity increases the chances that parts of it will be re-used and improved, changes which you can reincorporate later.
๐Ÿ“– Document what you make
Document your process, ideas, designs and code. Help others benefit from your journey โ€” including your future self!
๐Ÿฅซ Make it last
If society can preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build durable web technology that doesnโ€™t require destroying everything every few years in the name of progress.

See Also