use what you make

From IndieWeb


use what you make is an IndieWeb principle that encourages creators to use the applications, tools, libraries, code, designs, documentation that they create, in particular on their personal website, and the counterpart of the make what you need principle. The phrasing of this principle was inspired by this quote:

Build what you need. Use what you build.John Seely Brown quoted at eLearning 2015[1]

On the IndieWeb, “use what you make” means using your creations on your personal site as an aspect of your primary online identity, day to day.

Why

Clearer perspective. Whether code, UX, design, or content, there is an aspect of depending on your creations personally yourself, beyond just testing a project you’re working on, that changes how you see your creations, their flaws, and what to focus on next.

Prioritization. Fix more important problems first. When you use what you make, you empathize as a user and fix the important problems first. You see and feel the impact of problems in what you have built, and in particular feel the difference between minor problems and major problems, thus helping you prioritize fixing the more important problems.

Fix most visible problems first. By using what you build as your personal identity on the public web, when there are visible problems, you will feel self-conscious about it, and strongly motivated to fix them quickly.

Faster iteration. Fix the more important problems faster. Using what you make helps motivate you to fix the important problems faster.

If not you, then who? [should bother using your stuff] If you're not willing to use your creation on your own primary personal website, why should anyone else use it on their primary personal website?

Creations tend to break (stay broken), when their creators don't use them. In general it is a good idea to use code that the author is using themselves. Those are less likely to be broken.

How to

Using what you make, has several required components, one of which is actually using the thing, but the other is the essential making part of use what you make:

  1. active creation - whether code, UX, interactive/visual/graphic design, being an active creator
  2. use of what you create (e.g. by your company, on your company's site, your club's site, etc.)
  3. personal - use of that creation - you yourself personally using your creation for your own personal uses - it's not (just) a job use (i.e. that you can shut off when you go home), it's a personal use.
  4. identity - use of that creation in what you identify as your self. The act of creation alters an aspect of the public "self" of the creator. On the web, this means use of that creation actively on your personal website that you primarily use to identify yourself to others. I.e. not on a test site, nor a hobby site, nor an occasional use site, but your primary personal site and thus as part of your primary identity on the web.

IndieWeb Examples

In rough order of when IndieWeb community members started using at least some part of what they build, using their own primary web identity presence with their own domain.

Tantek

Tantek Çelik uses personal publishing software Falcon he wrote, including its open source functions in CASSIS live on his own site tantek.com since 2010-01-01.

  • He often deploys and tests CASSIS updates on his own site as a final live test before committing them to the cassis github repo, figuring if its going to break in production, he'd rather it break first on his site, than someone else's site who is depending on CASSIS.

Kartik Prabhu

Kartik Prabhu uses his website code Bundle on his site kartikprabhu.com since sometime in 2013

Dmitri Shuralyov

Dmitri Shuralyov uses his issue tracker on his personal website. He uses it as the canonical issue tracker for the issue tracker itself, as well as to drive his blog (source), and a list of idiomatic Go suggestions (source).

capjamesg

capjamesg uses code he wrote:

  • a webmention endpoint he built to accept all incoming webmentions.
  • his Micropub client to post content to his site.
  • the IndieWeb Search engine he is building to answer questions he has about the IndieWeb.

He uses his own notification tracker on his personal site to read all his notifications. Notifications come from GitHub and additional sources.

Jae Lo Presti

Jae Lo Presti uses a custom blog engine on her website in an effort to learn some new technologies. It is made with some degree of compatibility with Hugo in mind.

She also uses this blog engine on other websites she owns, as the deployment is extremely trivial and customization is at the center of it.

  • add yourself...

Limitations

  • Beware of this trap: "only the people who wrote it can reliably use it" that OpenID fell into per this twitter thread

Perspectives

  • "Is its creator living and breathing it in his day-to-day online life? If so, awesome, if not, yawn." - Tantek 2013-01-03 11:05 (PST) (originally posted as a comment on a Google+ post).
  • If I make software for [someone else], am I ever going to rely on it? Unlikely
    If I make software which solves my own problems in a useful way, might others find it useful? Much more likely. - Barnaby Walters (2013-08-21 in iRC)
  • I have a higher tolerance for my own stupidly designed interfaces than [another person] would, but at some point I'm going to get frustrated by inefficiencies in my interface and make it better for me, which then makes it better for everyone. - Aaron Parecki (2013-08-21 in IRC)

Metaphors

eat what you cook

eat what you cook was created as a metaphor replacement for selfdogfood.

live in your ideas

It’s not enough to merely have ideas, a creator must inhabit them as they do their home:

Metaphorically speaking, a person's ideas must be the building he lives in - otherwise there is something terribly wrong. Søren Kierkegaard, introduction to Provocations

FAQ

Unverifiable commits

What about sites that are running non-open-source software (no way to directly verify commits)?

A: Even web sites running software that is either little or not at all open sourced can still be analyzed for what features they use in terms of :

  • outward visual appearance and user interface
  • external notifications (e.g. PuSH and webmention behaviors)

Thus even if specific code commits are not transparently visible, there are plenty of other direct and indirect sources of evidence for creative (code, UX, design) changes, and thus the create/use pairing can still be verified to some extent.

See Also