This article is a stub. You can help the IndieWebCamp wiki by expanding it.
selfdogfood is a specific form of dogfooding, that is, using your own creations on your own personal site that you depend on, day to day.
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
Selfdogfooding has several required components, the first two of which it shares with dogfooding:
- active creation (whether code, UX, interactive/visual/graphic design)
- use of that creation (e.g. by your company)
- personal use of that creation - you yourself personally using your creation for your own personal uses - it's not just part of your day job that you shut off when you go home.
- self identification/dependency - using your creation in some manner that represents you, your self, e.g. as part of your primary identity on the web. The act of creation alters an aspect of the public "self" of the creator.
- "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).
- "any web server software that isn't actively selfdogfooded by its creators on their own personal domains is fragile and should not be trusted. and if web software creators themselves don't have a personal domain they use on the web then the web software is categorically untrustworthy." (speaking to the unfortunate demise of Open Photo, e.g. on Barnaby's site, and the screenshots on there that he'd linked to from patterns/note-list#Documented_Examples & patterns/note#Documented_Examples) Tantek Çelik 2014-05-12 in IRC
- 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)
Posts about selfdogfooding (most recent first)
It has come up in discussion several times that a more appealing term should be used. No consensus has been reached yet.
Please add IRC links and summarize discussion...
- gRegor Morrill likes the simple phrase "use your own product" or UYOP if an acronym is preferred. It's simple and to the point.
- Drinking your own champagne, or self-champagneing
- or just champagneing; doesn't need distinguish it from a preexisting term
- Self-kool-aiding — also has the connotation of buying into your own spiel
- Build your own lightsaber — unsure of origin, but I heard it used in this video. gRegor Morrill
Use and development
Are there two dimensions to selfdogfooding: use and development?
A: There are many required aspects of selfdogfooding, use and development only two of them.
Content updates but no commits
Would a site that is regularly updated with posts but not have commits for a while qualify as selfdogfooding?
A: At some point if there are no creative (code, UX, design) commits by the self-identified primary user of said site, then they've shifted from dogfooding (which requires a creation/use feedback loop) to simply being a user. No, eventually, after "a while", that should not be considered selfdogfooding.
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.
testing your code in production
Whilst testing your code in production is a good part of selfdogfooding, security precautions should still be taken. Showing errors, warnings and notices usually reserved for dev environments is a huge security risk due to the fact that things like paths, usernames, secret keys, etc. might be inadvertently shown to anyone who cares to look. It’s also not a great idea to have confusing error messages intermingled with content.
Rather, you should log all such messages somewhere where only you can see them, or only show them in-page if you’re logged in as an admin.
In PHP, there are several ways to go about this.