My wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Introduction

These case studies will evolve as we have switched methodologies

IndieWeb is a community of people build and use personal websites as “a people-focused alternative to the ‘corporate web’” (IndieWeb.org, 2018). IndieWeb’s contributors build and use tools to help web creators own their own content by hosting it on their own Web domain. On its homepage, three reasons are presented for using the IndieWeb instead of centralized platforms: “Your content is yours”; “You are better connected”; and “You are in control” (IndieWeb.org, 2018). To achieve these goals, IndieWeb's community publishes web content to personal websites, rather than relying on corporate platforms. IndieWeb sites are configured to communicate replies, likes, and other social media interactions directly to other sites, without a platform acting as intermediary. The community places an emphasis on people rather than platforms and therefore tries to provide tools that allow people to interact on commercial silos.,[a][b] IndieWeb sites also syndicate posts to various platforms, and then aggregating responses from across those sites back to the original post.

By contrast with the other case studies presented in this book, IndieWeb was not built by educators with pedagogy as its primary purpose. Instead, it was created by web developers with the goal of taking control of their online identity. ~It holds lessons for open pedagogy through its members’ shared practices of creating websites and related tools, which present a model for self-directed learning in a community devoted to openness.

Whereas the previous cases highlighted ways in which open pedagogy extends beyond the classroom, IndieWeb lacks formal roots in educational traditions altogether. It is not pedagogy brought into the wild, but instead is of-the-wild in the first place. The learning and knowledge sharing that occurs at this site provide valuable insights about how open pedagogy can thrive beyond the confines of the classroom.
History

IndieWeb was conceived after co-founders Aaron Parecki and Tantek Çelik attended the 2010 Federated Social Web Summit. The two connected with Amber Case and Crystal Beasley to continue in spirit and goals of the conference, but using a different approach. According to Amber Case, the "2010 Federated web summit too much talk not enough build."

The group wanted a more production based approach "Let's write this spec, and start this mailing list, and what about this idea," Case continued in a criticism of w3c efforts to around the social web. Çelik has noted that most participants at the summit were focused on “what could be possible [in the future]” rather than “what was possible [now]” (Çelik, 2014).

The following year in 2011 the group worked to organize the first IndieWeb Camp event in Portland, Oregon. The event was focused on discussing and building tools to own one's own data on a personal website "rather than posting content on many third-party silos of data" (“IndieWebCamp,” 2011). The instructional design followed a barcamp model, the protogenesis of EdCamps. Tantek Çelik also helped to launch BarCamps.

Amber Case explained why early on IndieWeb camp put such a focus on building from your own site first."The whole point is you implement something and you show it to the community. Whoever has the best story doesn't win, the best implementation wins." This approach reflects a common commitment among computer scientists to making; for an idea to be taken seriously, it should be demonstrated by building a working system (Agre, 1997). One of the merits to this approach is that making can surface problems that are hidden until an idea is realized in the real world. As Case continued, "You can't make the perfect spec. That is a Platonic ideal."

IndieWeb’s commitment to making extends through its communication systems. After the event, a decision was made not to keep in touch via an email list, but instead to use the Web itself. Çelik (2014) explained this choice, "You're not going to email your way into building a website. So we said we don't need it, we're not going to use email. We're going to use the web itself to build the web that we want."

IndieWeb has grown significantly in the intervening years. Between 2011 and 2018, IndieWeb's community has held over 600 events in cities across North America, Europe, and other Western countries (“Events - IndieWeb,” 2018). In 2017, an member of IndieWeb's community named Ryan Barret identified over 2300 of the most active IndieWeb sites around the world (Barrett, 2017), and thousands of people have posted online to IndieWeb's wiki and chatrooms. To date over one million Webmentions, a tool that allows IndieWeb sites talk together, have been sent.
Shared Goals as Community

Overall having your own place on the web is the rallying cry of the IndieWeb. As one member notes, "Have a home, express myself, and internet citizenship" (Slatkin, 2012). As described earlier, IndieWeb’s website promises to enhance people’s ownership, control, and connectedness. Çelik has summarized that these three goals are rooted in a commitment to “self-empowerment” (Çelik, 2016).

IndieWeb’s community is oriented around a belief that building personal websites can be a means to empowerment.

As one participants notes:

Now I’m not a Web Developer, but I think I’d like to try my hand at it. I don’t need to centralize all of my data but I would like an online presence that I control. Something that I could constantly work on. Something that’s never finished. Much like the web itself.

The building your own space also connects to the shared value of "show don't tell." The idea of showing before talking became a central organizing tenant of IndieWebCamp. In fact the first principle suggested by the community revolved around self dogfooding:

Eat your own dogfood. Whatever you build should be for yourself. If you aren't using it, why should anybody else? More importantly, build the indieweb around your needs. Others can do likewise. (Morris, 2012).

While there is debate to the etymology of the term of "eating your own dog food" the phrase grew in popularity in the tech world in when in 1988 a manager at Microsoft sent an email titled "Eating your Own Dogfood" that described using the products before you build them.

This driving principle influences much of the early web community. In fact in the community detailed how they were not planning for the masses and specifically noted they "were not designing for all." While this did create inequities and reinforce traditional barriers of access in technology it assumed a smaller platform for testing and developing technology.

This is why I think it is exciting that the IndieWeb inherently follows this method. Work small, demo, integrate into the whole what works, and you get this emergent structure out of that that’s resilient, with things evolving at the edges out of people exploring new projects. (Case, 2014).

These examples highlight personal empowerment – building for oneself means creating something useful for oneself. Yet,these efforts for individual self-empowerment are part of a larger goal to build a network of interconnected sites that can communicate with each other. To this end, IndieWeb’s community coordinates their activities through in-person and online collaborative spaces, including events, chat rooms, a wiki, GitHub, and communications directly between IndieWeb sites.

Overall community is essential in to IndieWeb and much of the energy originally poured into code by key organizers and founders now goes to to supporting the community. There are 3726 mentions of community minus WordPress and Mozilla. 4027 mentions of community when you include allies. 311 mentions of diversity, 113 results for inclusion,399 mentions of conduct when you remove wiki edits #IndieWeb. As co-founder Aaron Parecki notes:

"Community is a huge aspect. It is a big differentiator. We are all working on a shared goal but we are all doing it by having our websites talk together and work on the problem together."

As well as IndieWeb's immediate community, its members value connections to friends and family who do not operate personal websites. IndieWeb sites are commonly configured to syndicate posts to popular platforms such as Twitter, and then copy retweets, likes, and other responses back to one's personal website.

[This] is about staying in touch with current friends now, rather than the potential of staying in touch with friends in the future. --https://indieweb.org/POSSE

This highlights IndieWeb's commitment to working with current real-world systems instead of imagining an idealized future.
Membership and Barriers

    Defining membership

    Operating a personal website with indieauth, webmentions, microformats
    Logging in to IndieWeb.org, participating in IRC/Slack discussions
    Peripheral communities (use of #indieweb and related hashtags on Twitter); IndieWeb sites can POSSE to communicate with people on various platforms

    Identifying barriers

    Requirements to be a builder

    Initially, formal requirements, but these are relaxed

    Cost of operating personal website
    Technical skills for operating personal website

    Models for growth

It is somewhat difficult to draw boundary defining IndieWeb’s community. The creator of indiemap.org, a topographical view of IndieWeb’s “social graph”, noted a distinction between “IndieWeb in spirit”—”Any website that’s your primary online identity” and “IndieWeb in practice”—sites that adopt IndieWeb technical standards (Barrett, 2017). Participation in the IndieWeb typically involves both dimensions, so we consider IndieWeb’s community to consist of people who operate a website with one or more IndieWeb standards, and who use that site as their primary online identity.

There are other avenues to legitimate engagement with IndieWeb’s community such as attending IndieWeb Camps, Homebrew Website Clubs, or engaging in conversations online. Furthermore, due to IndieWeb’s practice of syndicating to popular platforms, it is possible to engage in conversation with IndieWeb’s community simply by replying to syndicated tweets or other posts. However, this is typically not sufficient to be recognized as a member of the IndieWeb, and a personal website remains an essential aspect of membership.

Operating a personal website requires a personal investment of time, as well as a financial investment to register a domain name and usually to pay for web hosting. This presents a potential barrier for participation, since members must be willing to build and operate a personal website. Early IndieWeb events had formal requirements that participants had to be creators, "someone that actually creates on the web with your own website" (Çelik, 2014). Those requirements have been relaxed, but having a personal website remains a de facto requirement for most participation.

"Number One thing you have to do is sign into the website. If you didn't have your own domain you could talk all you wanted to but you had to show at least you are dedicated to the cause of owning your own data." "This filtered out the didn't want to do the iota of work, these people are interested in talking but they don't implement." (Case, 2014)

After 2014, when Çelik attended an anniversary party of the Homebrew Computer Club, a hacker group attended by Steve Jobs and Bill Gates, he proposed adding a Homebrew Website Club. Since that time there have been hundreds of people onboarded to the community. In fact a search of IndieWeb chat records reveal 112 posts from people mentioning HWC and 5618 post for "first IndieWebCamp. This marked a shift in the organization to more open membership from the exclusionary role of focusing specifically on developers who could spin up their own websites.

The relaxation of the membership requirements also aligned with a large increase of press in 2013-2014,.IndieWeb received significant press coverage in Wired (Finley, 2013), Slate (Gillmor, 2014), and Gigaom (Ingram, 2014a, 2014b) and This Week in Google (Marx, Wermuller, Riley, 2014). This lead to an expansion of people to the IndieWeb and there are now 5618 posts cataloged in the chat archive about "first indiewebcamp" (minus your).

Still, technical barriers existed that made much of the IndieWeb unavailable to the masses. As noted this was by design. "Designing for the masses" is considered an anti-pattern of the IndieWeb, which are practices antithethical to the community. The wiki notes,

Designing for "mass adoption" is one of the traps that many past federated/social web efforts fell into.

It's a form of distraction: instead of designing/building what's immediately useful to you, the creator, you end up ratholing on what "everyone" or "the average person" seemingly wants, https://indieweb.org/antipatterns

This approach, while drastically increasing barriers to entry also protected the community of developers. There are two main developers and maintainers of all the IndieWeb WordPress themes and plug-ins. The focus on self-dogfooding versus building for the masses ensures tools get iterated and tested by the needs of the maker.

This is related to Indieweb’s commitment to implementation over ‘the best story’

    Plurality - build for oneself, support multiple impelmentations interoperating
    Plurality as a means of resolving disagreement
    Establishes a convention where the ability to build is an important part of having one’s voice heard. Disagreements may be addressed rhetorically through discussion, but if this is insufficient, the best implementation wins.

To this end the community has used a model that groups indieweb adopters into "generations" with gen1 developers getting further from everyday gen4 users as "Each Generation should be best at explaining IndieWeb to the next Generation. Each Generation should focus on filling in the gaps between one generation to the next" creating a staircase approach to knowledge dissemination. In fact as soon as you get to gen2 users suddenly technology must be done "With a wizard to help them cast the spells." In terms of gen4 users and the IndieWeb, "Introducing Gen4 to the IndieWeb is not yet reasonable at this time."

While the Generations page has not been seriously updated since 2014 the community has made strides to redefine loose membership as

"Be able to share and discuss and publish from your own website and ideally from your own domain name in a way that is not adversely controlled by another company" (Werdmuller & Downes, 2018).

In 2018 the barrier to membership and events was lowered further with a goal of attracting more event organizers. At the 2018 NYC leaders meeting it was decided to add an entry level event of IndieWeb meetup for people who found the word "club" or "Homebrew Website Club" exclusionary based on assumed required work of recruiting members and having repeated events.

Membership in the community was also signified by the use of microformats, a special kind of markup data used in HTML. Microformats were first used in 2004 but were largely abandoned by large search engine companies which in turn influenced to the metadata used by those seeking favor with search algorithms. Many of the IndieWeb building blocks use microformats to communicate with each other.

While symbols hold communities together (Dewey) and often unite affinity spaces (Gee) they can also act as walls for potential members who may not understand or choose to adopt these sign systems. In terms of the IndieWeb community discussions around web standards historically reflected an argumentative discourse prevelant. The founders themselves cite the "RSS/Atom Wars" as a demise in the early blogospher (Case, 2014, Çelik, 2014).

While recent efforts have been made to reduce "snark" on some of the pages of the wiki, the site does have a history of placing increased bias on different strategies that the community may find as "anti-pattern." See https://indieweb.org/bitcoin. for example where the crypto-c This form of discourse may not be inclusive to all participants and may represent a barrier to membership.

While the majority of those who self identify as IndieWeb use microformats to connect their website they do now use a membership gateway of "having your own website." However the community still uses the lens of "show and not tell" any technology for the social web that doesn't have two examples of people using the metadata structure and two examples of something consuming the data is considered "talk." The IndieWeb community, through the use of microformats, has gotten closest to a social web from personal websites, and is one of the few technologies to pass the show and not tell.

Overall microformats demonstrate the power of signs and symbols to sustain a community. In terms of socio-technical system the use of microformats also acted as a barrier to membership. While still in compliance with web standards microformats works on websites the same way as CSS, which controls the way pages look such as colors and fonts. This caused large technical difficulties for CMS platforms. A recent proposal (IndieWeb/Berlin, 2018) discussed using the property tag commonly used by RDFa, a different metadata type.
Leadership and Barriers

Given the already stated barriers of access inherent in the community, the access to leadership still aligns well to Gee's Affinity space model. To attend, what was called the "Leaders" meeting a person had to organize at least two Homebrew Website Club events in the previous year. All Leaders meetings were usually streamed, though not recorded, but documented on an etherpad. This etherpad is archived but a version is converted to a page on the wiki.

Efforts have been made to increase the number of organizers and to diversify leadership. Recently the decision was to change from 'leaders' to 'organizers' represents an effort to make the path to leadership more accessible. Notably, it is intended that anyone can become a 'leader' and the terminology was off putting (private citation).

With so many global events privledge, as in many facets of life, also creates barriers to leadership. Many organizers have professional arrangements with employers or work remotely as digital nomads. While a remote feed is made available hours of household silence maybe impossible in households with children (private citation).
Content Creation

Creation is a central feature of IndieWeb.

Building personal websites requires (at least) two types of creation. First, one must design the site itself, choosing a visual style and information structure that fits one's purpose. Second, one must populate the site with content.

Most of IndieWeb's novelty relates to the design and structure of personal websites. The content on most of these sites is equivalent to what can already be posted on various social media platforms, such as status updates, articles, photos, videos, location checkins, and activity logs of various kinds.

Although the overall breadth of content on IndieWeb sites parallels that of social media platforms, the scope of any given individual website varies significantly. Determining a unique blend of content-types for one's website eludes to Franklin's holistic technologies (described in Chapter 3) (##Cite Franklin 2004), which provide their operators opportunities to guide the entire making process. Although decisions over one's personal website are individual, they are often guided by community suggestions on IndieWeb's chat channels, or less directly influenced by seeing others' examples on their own sites.

Beyond personal websites themselves, IndieWeb's community collectively builds the infrastructures upon which those sites are supported.

Examples of IndieWeb building blocks

 

Type of building block
	

Example

Technical standard
	

The Webmention standard is used to send 'mentions' between websites. Microformats 2 is used to mark up content metadata for machine readability. Together these standards allow websites to exchange replies, likes, and other types of social actions.

 Web application
	

Brid.gy is used to syndicate content from personal websites to various social networks. Monocle.p3k.io is used to follow and interact with feeds from other websites

Plugin for existing software
	

A variety of plugins for adding IndieWeb features to sites built using the popular WordPress content management system.

Conventions of practice
	

Publish on Own Site, Syndicate Elsewhere - A convention for owning one's data while still engaging with various social platforms

The list above presents a partial view of IndieWeb's building blocks. IndieWeb sites rely on combinations of these building blocks to suit individual needs. Standards, software, and practices are tightly integrated. As a result, creating these building blocks requires coordination across multiple actors, which highlights the importance of knowledge brokering through building practices.
Agentive Apprenticeship

There are 785 mentions of "my first" 381 mentions of "don't know how" and 1682 mention of "learn" 501 mentions of "itches" 515 for "itch" (minus edited to remove wiki edits) 439 results for goals (also not accounting for wiki edits) in #IndieWeb chat logs
References

Agre, P. (1997). Computation and human experience. Cambridge ; New York: Cambridge University Press.

Barrett, R. (2017, June). Keynote: Indie Map. Presented at the IndieWeb Summit 2017, Portland, OR. Retrieved fromhttps://snarfed.org/indiemap_iws2017/assets/player/KeynoteDHTMLPlayer.html#15

Çelik, T. (2016, June). State of the IndieWeb. Presented at the IndieWeb Summit, Portland, OR. Retrieved fromhttps://www.youtube.com/watch?v=7zTolqW_I2g

[a]Thinking about rephrasing this - just marking it for rethinking. rather than "friends & family" could frame this as part of IndieWeb's emphasis on people rather than platforms,

[b]I like the thinking about the individual...as opposed to the network...or the silos we exist within.

There is also a need to indicate that this is a challenge as the network makes it easier for you...and you may not easily be able to connect with your "friends & family."