Azure Jane Lunatic (Azz) 🌺 (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
azurelunatic) wrote2010-04-08 03:22 am
azurelunatic) wrote2010-04-08 03:22 am
Entry tags:
Why I think Dreamwidth is a special Free/Libre Open Source Software Development Environment
Why I think Dreamwidth is a special Free/Libre Open Source Software Development Environment, and what I think is important about being a Dreamwidth contributor, by Azz, aged 29 3/4
Right, that's the soulless corporate drone version. Let me relate the history as I know it.
Basically, a couple people said, "You know, we're just waiting for you to start up your own blogging site." Dreamwidth's owners looked at each other and said "You know, we could do this." They did this not because the blogging end of social media was where the money was, but because they blog, their friends blog, and they wanted to see social blogging done not just reasonably well, but right.
Denise, the Suit, was previously a manager at LiveJournal.
Mark, the Geek, was previously doing things at Mozilla, LiveJournal, and Google.
The Suit looked at some of the complaints about the diversity attempts from other existing sites, and decided that part of the problem was that some other sites tended to treat its target audience as a sighted, English-speaking, (currently) able-bodied Caucasian male with the ability to memorize the menus and read the designers' minds about where things are kept, with people who did not meet that model tacked on as an afterthought: "oh, yes, you other 'diverse' people can use the site too if you want to".
She and the Geek decided to make the site actually welcoming to as broad as possibly practical a range of incoming users as possible, starting with the diversity statement. This process did include a forlorn meep of "But ... I'm a sighted, able-bodied, politically conservative Caucasian male... am I welcome here too?" from the Geek, until the diversity statement was edited once again. (The actual construction of the diversity statement was partially crowdsourced, if you count tossing the draft to one's journal readership and letting them have at it as crowdsourcing. I'm proud to say that I had a hand in it.)
A year on down the line, I can still point to the diversity statement and say: "This. The site I now use every day called for my contributions, and this is the first mark that I made." Every time I hear someone praising the diversity statement, especially when they mention the part I contributed, I feel the clean pride of a job well-done. I think "It may not be much, but it makes a difference to me, and to other people who use the site every day."
Dreamwidth found itself in a delicate position as a startup, breaking into a niche already dominated by LiveJournal, the original project from which Dreamwidth was forked. The owners knew that while there was a not insignificant audience in users who had been alienated by various of LiveJournal's practices, that this audience alone was not a sustainable userbase -- nor would people (them included) ultimately want to use a blogging site that set out to define itself as "Not LiveJournal". They could not compete directly in terms of volume, and so did not set out to capture the exact same audience or attempt to become LiveJournal's replacement. Instead, they determined that they would become the type of blogging site that they themselves most wanted to use, and incidentally fix all the nagging things they'd never had time to fix when they were working for LiveJournal.
People were eagerly waiting for the site to launch. (Archives of the dw-discuss mailing list, from active discussion starting June 2008 to Open Beta launch at the end of April 2009, with trailing messages in May and July 2009.) The culture of the pre-launch mailing list was largely power users of the existing LiveJournal codebase who desperately wanted the new service to be off the ground as soon as possible. To help it launch as soon as possible, they wanted to know what could be done to help out. Both the owners were used to the crowdsourced model of technical support from LiveJournal. Instead of recruiting experienced developers only, the owners asked for help splitting up what had to be done, and asked for help with every conceivable part of site building.
Design suggestions from elementary users, basic users, and power users were considered along with implementation suggestions from actual developers. In keeping with the accessibility statement, there was a conscious choice to meet user expectations about design, rather than build the site to developer expectations and expect the users to learn how it worked. Even though elementary users were not expected to know anything about actual development of a website, they were expected to know what their own expectations for a website were (such as what they might expect under any given menu header), and what sorts of things they would like to see, and what sorts of things they hoped to never see again. The feedback from up and down the line was collated to help rebuild parts of the site like the menus.
Crowdsourcing can only take a project so far. The owners maintained a firm grasp on their own broad vision of the site, and while they allowed discussion to ramble and free-associate and split hairs, they had the final say and gave up very little creative control. As their vision was still fairly high-level on many things, with "find the best precise route by consensus" on some of the details, they did not have to assert their control too often.
Part of the diversity that the owners made their commitment to was accessibility. The owners made the choice at the outset to consult experts in the area of accessibility, rather than tacking on accessibility as an afterthought as so many websites do. Instead of hunting down self-proclaimed experts whose only claim to expertise might have been a cursory study of the standards, the owners reached out to the contributor pool and asked for users who already used keyboard-only navigation, voice control, screen readers, large display, text-only browsers, high-contrast displays, low-light displays, and so forth. They solicited feedback on the existing codebase and what improvements should be made. From this feedback pool, the owners found that there were already competent developers and other practical experts, and quickly recruited them for ongoing active assistance.
Ongoing consultation with experts in practical accessibility changed the development style of regular contributors. Rather than designing explicitly for a sighted user with a particular browser and screen size, with full use of images, scripting, keyboard, and mouse, design became more information-centric, with styling laid on top. Regular contributors became able to catch the usual erroneous assumptions, and started educating other contributors. This means that there is far-reaching practical accessibility evangelism spreading out from Dreamwidth contributor culture into the greater development and software design world.
The user-involved design led to a development culture where the contributions of each individual contributor were not just valued based on the amount of experience the person had, but valued inherently for themselves, whether or not that particular contributor ever did anything for the site again. The owners made an effort to attempt to thank everyone who showed an interest in helping, and thank everyone who made a contribution, even if that contribution was not ultimately usable. This resulted in more return contributors, and contributors who were willing to take a contribution that was not initially accepted and return with improvements to make the contribution more suited to the project. (No project is perfect; I know there were a number of people who wanted to help at the outset but who got lost in the shuffle or otherwise turned off.)
From the top down, there is very little distinction drawn between "user" and "contributor". The project takes the approach that every user, no matter how technically inexperienced, is either already contributing or has the potential to become a contributor. Volunteer culture takes the basic attitude that everyone asking questions about the site is looking to be educated, everyone who wants to learn is capable of learning if it's explained right or often enough, and there is no ceiling on the amount of information any given person can absorb over their lifetime. The volunteers who came to the Dreamwidth project from LiveJournal support have seen users who were having difficulty with their basic settings turn into seasoned technical support staff and even management; the volunteers who came in fresh to Dreamwidth have seen equally new and blundering people pick up experience and develop into highly skilled professionals.
Even some of the smallest things are considered contributions.
Developers come to Dreamwidth from two sources: existing users of the site who are interested in taking their contributions to the next level, and existing developers who have heard about Dreamwidth from friends who are involved or general buzz in the FLOSS community.
Not all of the existing Dreamwidth users who enter Dreamwidth development were experienced developers at the time they began. The Suit never intended to become a developer, it just happened. She had started creating tiny patches to keep busy and help out the Geek, and gradually this became bigger and bigger patches. This tradition continued with other contributors-turned-developers, and has led to a growing pool of developers, each pulling the next by their bootstraps.
The Geek has overseen the setup of procedural and social infrastructure to support the training of the new developers (called "babydevs" in project slang), including existing people pointing the babydevs to the right documentation, and walking them through relevant tasks. In the stereotypical FLOSS environment, someone asking an obvious n00b question might get (in various levels of harshness) "Have you read the docs?" with the implication that until you have read the docs, you are not worthy to be asking any questions in this forum, and that if you do not understand the docs, you are either utterly unworthy, or you need to take yourself back to the docs and study them until you have attained enlightenment. In Dreamwidth development, "Have you read the docs?" tends to be a lead-in to more focused discussion about a) what parts of the docs are likely to be most relevant to what you're working on, b) what obvious, every-Dreamwidth-developer-already-knows-this, woops, information was left out of the docs by accident, or c) starting with the information from the relevant sections of the docs as a baseline of common knowledge and building from there.
Anyone can view (most of) Dreamwidth's Bugzilla installation (security-related bugs are filed privately), and anyone can create an account and start assigning bugs to themselves and uploading patches. The Geek, or his deputies, review all submitted patches for not just general soundness, but also adherence to the Dreamwidth coding standards. Rather than pass/fail feedback, the results of this review generally include a written, sometimes line-by-line, evaluation of why any given patch was not accepted, or (if accepted) notes on what could be improved next time, or what the experienced developer changed in the version of the patch that was ultimately used. Generally, when a patch is not accepted, it is returned with notes on what would need to be done in order to make it acceptable. This practice results in not only better programmers (from the constant code reviews) but programmers who have been carefully trained in the senior developers' preferred coding styles. :D
The Dreamwidth codebase is an unwieldy thing, and often difficult to install and configure.kartik and vass have both recently earned high distinction by installing Dreamwidth on their own development machines from scratch. Most Dreamwidth developers use a Dreamhack (hosted Dreamwidth development environment), where the worst part of the setup is done for you, and all you have to do is develop.
Dreamwidth volunteer culture has significant differences from the general English-speaking technical community. Consider the contents of the average technical-community IRC quotes database, such as bash.org or QDB.us. Gender balance in technical fields skews male. Dreamwidth development is majority female, and regular contributors have significant other minority populations, some of which overlap. My favorite anthropomorphic portrayal of Dreamwidth is as a polyamorous black lesbian wheelchair user. Incidents from the greater IT field such as the racist AI support bot demonstrate that when the average bunch of geeks are left alone, the tone of the conversation will degenerate, to casual (or "ironic") racist language, sexist cracks, and other forms of horror. Even mildly racist, sexist, ablist, homophobic, transphobic, etc. comments which are generally brushed off by people hardened to them from constant exposure tend to get a firm negative reaction from all over the channel; tales of sexism/racism/etc. in the wild seem to be more often greeted with "What a jerk" than laughter, even laughter that's clearly at the expense of the jerk in question. Garden-variety tiny but gender-stereotyped moments like someone assuming that the Suit answers to "sir" are handled politely and firmly. #dreamwidth IRC's quoted humor skews far more to wordplay and geeky jokes than does representative portions of popular QDBs.
As both the owners speak English, development and primary volunteer culture takes place in English, and the company is US-based. The site, however, has worldwide users, and there is usually always someone awake in IRC no matter what time it is. The project is written to make it easy to translate into other languages when installed elsewhere.
Because Dreamwidth is a social media site, people who develop for it, work on it, and volunteer for it also tend to spend recreational and social time on it, actually using the site as well as contributing. There is an ingrained reluctance to trust any would-be contributor who is not also willing to explore and use the site. If Dreamwidth development has any hazing rituals, it is this. A new developer has not really had the true Dreamwidth experience until they have run up against something in the site that drives them crazy when trying to use it, then turned around and filed a bug -- or found that someone else had already filed it -- or stomped over to Bugzilla and whipped out a patch to finally fix the damned thing.
But the true meaning of being a Dreamwidth contributor is being able to look at the site and say, "See that? I did that. This, here? That was me. I use this site, and I made it better for not just me, but everybody."
Dreamwidth is a social media platform with attention to diversity and accessibility.
Right, that's the soulless corporate drone version. Let me relate the history as I know it.
Basically, a couple people said, "You know, we're just waiting for you to start up your own blogging site." Dreamwidth's owners looked at each other and said "You know, we could do this." They did this not because the blogging end of social media was where the money was, but because they blog, their friends blog, and they wanted to see social blogging done not just reasonably well, but right.
Denise, the Suit, was previously a manager at LiveJournal.
Mark, the Geek, was previously doing things at Mozilla, LiveJournal, and Google.
The Suit looked at some of the complaints about the diversity attempts from other existing sites, and decided that part of the problem was that some other sites tended to treat its target audience as a sighted, English-speaking, (currently) able-bodied Caucasian male with the ability to memorize the menus and read the designers' minds about where things are kept, with people who did not meet that model tacked on as an afterthought: "oh, yes, you other 'diverse' people can use the site too if you want to".
She and the Geek decided to make the site actually welcoming to as broad as possibly practical a range of incoming users as possible, starting with the diversity statement. This process did include a forlorn meep of "But ... I'm a sighted, able-bodied, politically conservative Caucasian male... am I welcome here too?" from the Geek, until the diversity statement was edited once again. (The actual construction of the diversity statement was partially crowdsourced, if you count tossing the draft to one's journal readership and letting them have at it as crowdsourcing. I'm proud to say that I had a hand in it.)
A year on down the line, I can still point to the diversity statement and say: "This. The site I now use every day called for my contributions, and this is the first mark that I made." Every time I hear someone praising the diversity statement, especially when they mention the part I contributed, I feel the clean pride of a job well-done. I think "It may not be much, but it makes a difference to me, and to other people who use the site every day."
Dreamwidth found itself in a delicate position as a startup, breaking into a niche already dominated by LiveJournal, the original project from which Dreamwidth was forked. The owners knew that while there was a not insignificant audience in users who had been alienated by various of LiveJournal's practices, that this audience alone was not a sustainable userbase -- nor would people (them included) ultimately want to use a blogging site that set out to define itself as "Not LiveJournal". They could not compete directly in terms of volume, and so did not set out to capture the exact same audience or attempt to become LiveJournal's replacement. Instead, they determined that they would become the type of blogging site that they themselves most wanted to use, and incidentally fix all the nagging things they'd never had time to fix when they were working for LiveJournal.
People were eagerly waiting for the site to launch. (Archives of the dw-discuss mailing list, from active discussion starting June 2008 to Open Beta launch at the end of April 2009, with trailing messages in May and July 2009.) The culture of the pre-launch mailing list was largely power users of the existing LiveJournal codebase who desperately wanted the new service to be off the ground as soon as possible. To help it launch as soon as possible, they wanted to know what could be done to help out. Both the owners were used to the crowdsourced model of technical support from LiveJournal. Instead of recruiting experienced developers only, the owners asked for help splitting up what had to be done, and asked for help with every conceivable part of site building.
Design suggestions from elementary users, basic users, and power users were considered along with implementation suggestions from actual developers. In keeping with the accessibility statement, there was a conscious choice to meet user expectations about design, rather than build the site to developer expectations and expect the users to learn how it worked. Even though elementary users were not expected to know anything about actual development of a website, they were expected to know what their own expectations for a website were (such as what they might expect under any given menu header), and what sorts of things they would like to see, and what sorts of things they hoped to never see again. The feedback from up and down the line was collated to help rebuild parts of the site like the menus.
Crowdsourcing can only take a project so far. The owners maintained a firm grasp on their own broad vision of the site, and while they allowed discussion to ramble and free-associate and split hairs, they had the final say and gave up very little creative control. As their vision was still fairly high-level on many things, with "find the best precise route by consensus" on some of the details, they did not have to assert their control too often.
Part of the diversity that the owners made their commitment to was accessibility. The owners made the choice at the outset to consult experts in the area of accessibility, rather than tacking on accessibility as an afterthought as so many websites do. Instead of hunting down self-proclaimed experts whose only claim to expertise might have been a cursory study of the standards, the owners reached out to the contributor pool and asked for users who already used keyboard-only navigation, voice control, screen readers, large display, text-only browsers, high-contrast displays, low-light displays, and so forth. They solicited feedback on the existing codebase and what improvements should be made. From this feedback pool, the owners found that there were already competent developers and other practical experts, and quickly recruited them for ongoing active assistance.
Ongoing consultation with experts in practical accessibility changed the development style of regular contributors. Rather than designing explicitly for a sighted user with a particular browser and screen size, with full use of images, scripting, keyboard, and mouse, design became more information-centric, with styling laid on top. Regular contributors became able to catch the usual erroneous assumptions, and started educating other contributors. This means that there is far-reaching practical accessibility evangelism spreading out from Dreamwidth contributor culture into the greater development and software design world.
The user-involved design led to a development culture where the contributions of each individual contributor were not just valued based on the amount of experience the person had, but valued inherently for themselves, whether or not that particular contributor ever did anything for the site again. The owners made an effort to attempt to thank everyone who showed an interest in helping, and thank everyone who made a contribution, even if that contribution was not ultimately usable. This resulted in more return contributors, and contributors who were willing to take a contribution that was not initially accepted and return with improvements to make the contribution more suited to the project. (No project is perfect; I know there were a number of people who wanted to help at the outset but who got lost in the shuffle or otherwise turned off.)
From the top down, there is very little distinction drawn between "user" and "contributor". The project takes the approach that every user, no matter how technically inexperienced, is either already contributing or has the potential to become a contributor. Volunteer culture takes the basic attitude that everyone asking questions about the site is looking to be educated, everyone who wants to learn is capable of learning if it's explained right or often enough, and there is no ceiling on the amount of information any given person can absorb over their lifetime. The volunteers who came to the Dreamwidth project from LiveJournal support have seen users who were having difficulty with their basic settings turn into seasoned technical support staff and even management; the volunteers who came in fresh to Dreamwidth have seen equally new and blundering people pick up experience and develop into highly skilled professionals.
Even some of the smallest things are considered contributions.
- Everyone who reads and enjoys something on the site benefits from the site.
- Everyone who links to something on the site is contributing to knowledge and reputation of the site on the greater internet.
- Every user who posts an entry or a comment on the site is contributing to site culture.
- Every user who customizes their journal is contributing to their own and others' enjoyment of the site.
- Every user who deletes-and-reports-as-spam a spammer's comment is contributing to the same spammer not hitting them or other users in the future, and contributing to the antispam team's knowledge of spammer tactics.
- Every user who requests help is contributing to their own knowledge of the site.
- Every user who requests help is pointing out something that may be insufficiently self-explanatory.
- Every user who answers a request for help, or makes a general announcement answering common questions or drawing attention to cool new features, is contributing to others' knowledge of the site.
- Every user who points out something that they do not enjoy (a bug or just something gnarly-as-designed) is contributing to designer plans for future improvements.
- Every user who helps replicate a bug or tracks down the exact circumstances under which a bug occurs is contributing to the information known about that bug.
- Every user who suggests a change is contributing to designer plans for future improvements.
- Every user who comments or votes on a suggested change is contributing to designer plans for future improvements.
- Every user who suggests a change to documentation is contributing to the quality of site documentation.
- Every user who submits an answer to a Support request, whether or not it is accepted to send along to the user, is contributing to the crowdsourced Support experience.
- Every user who customizes or designs a style is contributing to their own and others' enjoyment of the site.
- Every designer who writes a specification for a feature or patch is contributing to the development project.
- Every user who considers contributing a patch may someday actually contribute one.
- Every developer who contributes a patch, whether or not it is accepted, is contributing to the development project.
- Every developer who has a patch accepted is contributing to the development project.
- Every user who reviews accepted patches and points out potential issues with the patch as written is contributing to the development project.
- Every developer who reviews accepted patches for quality and adherence to project standards is contributing to the development project and developer education.
- Every developer who takes the time to answer questions from another developer, particularly a less-experienced one, is contributing to project developer education.
- Every user who cheers on the contribution of any other user, no matter how small, is strengthening that particular contributor's experience and contributing to overall project morale.
Developers come to Dreamwidth from two sources: existing users of the site who are interested in taking their contributions to the next level, and existing developers who have heard about Dreamwidth from friends who are involved or general buzz in the FLOSS community.
Not all of the existing Dreamwidth users who enter Dreamwidth development were experienced developers at the time they began. The Suit never intended to become a developer, it just happened. She had started creating tiny patches to keep busy and help out the Geek, and gradually this became bigger and bigger patches. This tradition continued with other contributors-turned-developers, and has led to a growing pool of developers, each pulling the next by their bootstraps.
The Geek has overseen the setup of procedural and social infrastructure to support the training of the new developers (called "babydevs" in project slang), including existing people pointing the babydevs to the right documentation, and walking them through relevant tasks. In the stereotypical FLOSS environment, someone asking an obvious n00b question might get (in various levels of harshness) "Have you read the docs?" with the implication that until you have read the docs, you are not worthy to be asking any questions in this forum, and that if you do not understand the docs, you are either utterly unworthy, or you need to take yourself back to the docs and study them until you have attained enlightenment. In Dreamwidth development, "Have you read the docs?" tends to be a lead-in to more focused discussion about a) what parts of the docs are likely to be most relevant to what you're working on, b) what obvious, every-Dreamwidth-developer-already-knows-this, woops, information was left out of the docs by accident, or c) starting with the information from the relevant sections of the docs as a baseline of common knowledge and building from there.
Anyone can view (most of) Dreamwidth's Bugzilla installation (security-related bugs are filed privately), and anyone can create an account and start assigning bugs to themselves and uploading patches. The Geek, or his deputies, review all submitted patches for not just general soundness, but also adherence to the Dreamwidth coding standards. Rather than pass/fail feedback, the results of this review generally include a written, sometimes line-by-line, evaluation of why any given patch was not accepted, or (if accepted) notes on what could be improved next time, or what the experienced developer changed in the version of the patch that was ultimately used. Generally, when a patch is not accepted, it is returned with notes on what would need to be done in order to make it acceptable. This practice results in not only better programmers (from the constant code reviews) but programmers who have been carefully trained in the senior developers' preferred coding styles. :D
The Dreamwidth codebase is an unwieldy thing, and often difficult to install and configure.
kartik and vass have both recently earned high distinction by installing Dreamwidth on their own development machines from scratch. Most Dreamwidth developers use a Dreamhack (hosted Dreamwidth development environment), where the worst part of the setup is done for you, and all you have to do is develop. Dreamwidth volunteer culture has significant differences from the general English-speaking technical community. Consider the contents of the average technical-community IRC quotes database, such as bash.org or QDB.us. Gender balance in technical fields skews male. Dreamwidth development is majority female, and regular contributors have significant other minority populations, some of which overlap. My favorite anthropomorphic portrayal of Dreamwidth is as a polyamorous black lesbian wheelchair user. Incidents from the greater IT field such as the racist AI support bot demonstrate that when the average bunch of geeks are left alone, the tone of the conversation will degenerate, to casual (or "ironic") racist language, sexist cracks, and other forms of horror. Even mildly racist, sexist, ablist, homophobic, transphobic, etc. comments which are generally brushed off by people hardened to them from constant exposure tend to get a firm negative reaction from all over the channel; tales of sexism/racism/etc. in the wild seem to be more often greeted with "What a jerk" than laughter, even laughter that's clearly at the expense of the jerk in question. Garden-variety tiny but gender-stereotyped moments like someone assuming that the Suit answers to "sir" are handled politely and firmly. #dreamwidth IRC's quoted humor skews far more to wordplay and geeky jokes than does representative portions of popular QDBs.
As both the owners speak English, development and primary volunteer culture takes place in English, and the company is US-based. The site, however, has worldwide users, and there is usually always someone awake in IRC no matter what time it is. The project is written to make it easy to translate into other languages when installed elsewhere.
Because Dreamwidth is a social media site, people who develop for it, work on it, and volunteer for it also tend to spend recreational and social time on it, actually using the site as well as contributing. There is an ingrained reluctance to trust any would-be contributor who is not also willing to explore and use the site. If Dreamwidth development has any hazing rituals, it is this. A new developer has not really had the true Dreamwidth experience until they have run up against something in the site that drives them crazy when trying to use it, then turned around and filed a bug -- or found that someone else had already filed it -- or stomped over to Bugzilla and whipped out a patch to finally fix the damned thing.
But the true meaning of being a Dreamwidth contributor is being able to look at the site and say, "See that? I did that. This, here? That was me. I use this site, and I made it better for not just me, but everybody."