Presented at Freedom in the cloud miniconf, Linux.conf.au 2011.
Freedom in the Cloud miniconf
Wikipedian c. 2005-2010
Concerned with technical specs
Part Software Wiki
Interface Already existed with
Vast majority of
access via web UI.
Access point Possible but not
done, projects use
Community Kinda, like Linux? Not really
Multiple versions of articles
Opposite of “One True Version”
Some mechanism allows the best to “rise to the
top” (like PageRank?)
Isn't that like the internet before Wikipedia? …
Similar to Knol? UrbanDictionary? StackOverflow?
rewards older contributions
evaluating is boring
no canonical/reliable version
does not force/reward collaboration
“Marketplace of ideas” model
No more “One True Version”?
“A new-generation Wikipedia based on Git-style
technologies could allow there to be not just one
Ocelot article per language, but an infinite number
of them, each of which could be easily mixed and
merged into your own preferred version.”
– Anil Dash, “Forking is a Feature”
Wiki = VCS + prose text project + web UI.
Copyleft license => “right to fork” => “keeps the
(Software) releases : (wiki) approved versions?
English Wikipedia is 10. Can it survive to 20?
Too big to fail?
Too big to fork?
Wiki = web front-end for VCS
for prose text content
What's missing from wiki VCS?
Diffs need to be per-word, not per-line
Code contributions generally expected to be self-
contained, generally in larger chunks than
Code needs to be machine readable,
(optionally?) human readable. Onus is on
contributor to check machine readability
=> higher technical barrier to contributing is
Drive-by vandalism virtually non-existent
Prose projects rarely do “releases”
VCS for code vs prose
Merging for code vs prose
Code for unrelated technical functions should be
able to be merged
Can we make the same promise for prose?
Can Wikipedia survive another 10?
Sense of dissatisfaction in the community
Unlike software, a certain critical mass is needed
to stave off vandalism
Low barrier to entry
Wikipedia the monopoly
One destination –
convenient and simple
Great SEO (=> project
Potential for serendipity
in editor activities
Consistency (at least
MediaWiki has a write API!
# Init site object
site = mwclient.Site('commons.wikimedia.org')
site.login(username, password) # Optional
# Edit page
page = site.Pages['Commons:Sandbox']
text = page.edit()
print 'Text in sandbox:', text.encode('utf-8')
page.save(text + u'\nExtra data', summary = 'Test
“Pending changes” aka
“Pending changes” separates
“what change I want to make”
“what I want users to receive”
(tag as approved=”release”)
It's almost like
having a release branch
mixed in with trunk....
Parsing mark-up :(
Templates :( :(
Free license + API – what's the
Self-organised groups of editors dedicated to a
particular topic (e.g. Australia) or, less commonly,
focus (e.g. standardising dates)
Very informal, light-weight
Narrower focus => better opportunity for
Fork the UI?
(a la Twitter API)
“Why would anyone contribute to a
Promise of Wikipedia visibility
Domain-specific and relevant interface
What is community?
- for interacting
- for contributing
(eg. style guide)
Meta-planning for all of the above
If forking Wikipedia is too hard, what can we do to
make it practical again?
Screenshots and logos are © their respective owners
Wikipedia 10: David Peters, CC-BY-SA
Vandalism post-its: cdaltonrowe, CC-BY
Coloured post-its: Michael Goodine, CC-BY
Branches: Piotrus, CC-BY-SA
Wikimania schedule editing: Kat Walsh, CC-BY-SA
WikiProject Council logo: Neurolysis, CC-BY-SA
flagged revs maybe: Neurolysis/Kotra, CC-BY-SA
pending changes clock logo: Adam Miller/Anomie/Dodoïste, CC-BY-SA
This work is © Brianna Laugher and licensed under
the Creative Commons Attribution ShareAlike
license, except where otherwise noted.