Latest revision as of 20:17, 12 August 2015

Dreamwidth had a rocky start but has persevered, and built a large and thriving community. Here's how it stacks up against the "How to tell if a FLOSS project is doomed to FAIL" checklist of red flags, and some of the steps Dreamwidth takes to mitigate the problems.

Mitigation points: If you are using a Dreamhack, add the number of points indicated for Dreamhack users, rather than the BAZILLION points indicated for people installing on their own.

Size

The source code is ginormous, but at least it's pretty small when compiled.

+10

Mitigation: Dreamhacks, hosted development environments for anyone who would like to try development; experts in IRC who can often assist in locating the part of the code that the developer is looking for. +5 if you're using a Dreamhack.

Source Control

Currently using github.

+5 for git's learning curve.

Mitigation: git is the mitigation. So sorry.

Building From Source

• Documentation exists, but is dodgy, +10
• Configuration is not fun +15
• Oh god the build +150
• Oh god the tests +5

Mitigation: Dreamhacks. Dreamhack application process is +2.

Bundling

I think we're good here.

Libraries

+0 None of those issues apply.

System Install

This is a behemoth of code and it all needs to be exactly where it goes.

+50 for general pain and suffering

Mitigation: Dreamhacks. +5

Code Oddities

+10 for unspecified Brad-ness

Communication

• +15 no mailing list

Mitigation: All developers are expected to be users of the site; releases are announced in an on-site community dw_dev which can be configured to mail if so desired. Major releases are announced in the dw_news community, which mails to all site users by default. If you're a Dreamwidth user by preference, this is not a problem (+0).

Releases

(someone who knows more about the versioning should look at this and evaluate)

+50 absurd number of directories

• Your project does not do sanely versioned releases (Major, Minor) [ +10 points of FAIL ]
• Your project does not do versioned releases [ +20 points of FAIL ]
• Your project does not do releases [ +50 points of FAIL ]
• Your project only does releases as attachments in web forum posts [ +100 points of FAIL ]
• Your releases are only in .zip format [ +5 points of FAIL ]
• Your releases are only in OSX .zip format [ +10 points of FAIL ]
• Your releases are only in .rar format [ +20 points of FAIL ]
• Your releases are only in .arj format [ +50 points of FAIL ]
• Your releases are only in an encapsulation format that you invented. [ +100 points of FAIL ]
• Your release does not unpack into a versioned top-level directory (e.g. glibc-2.4.2/ ) [ +10 points of FAIL ]
• Your release does not unpack into a top-level directory (e.g. glibc/ ) [ +25 points of FAIL ]
• Your release unpacks into an absurd number of directories (e.g. home/johndoe/glibc-svn/tarball/glibc/src/) [ +50 points of FAIL ]

Mitigation: there's a process to update the Dreamhack against current.

History

+50 for the pain and suffering involved in forking this from LJ

+15 for the ~10 years of lj-com and lj-com-int or whatever the proprietary branches were; it's 50% because the lj branch was public-and-open-source.

Mitigation: the blood, sweat, and tears of Mark, denise, fu, exor674, and most assuredly others. See dw_dev's ~2008 entries for a taste of some of the anguish. +3 currently.

Licensing

I think we're mostly good here.

+2 on general principle.

Documentation

This is generally dodgy but getting better.

+20

Mitigation: The development community is actively working on converting the answers to neophyte developer/new-to-the-codebase questions into actual documentation on the wiki; questions asked in IRC have a good chance of getting splatted up on the wiki where they can be more formally expanded upon.

Culture

This is not a topic addressed directly by the original, although it's briefly touched upon. FLOSS communities in general have a reputation for abrasive cultures that discourage new developers from contributing code unless the code is already good enough, and for rejecting code with blatantly unhelpful remarks. Dreamwidth prefers a more constructive approach to developing new developers, and routinely rates bugs by their expected difficulty level, and picks out some specifically for beginning developers. Code reviews are intended to be constructive and educational, never personally insulting. IRC culture is intended to be friendly, welcoming, and minus the sexism, racism, disablism, and other misfeatures commonly present in FLOSS IRC areas by general reputation.

Dreamwidth started out with a large, active, and engaged community due to the situation that led to the forking process.

Dreamwidth has continued to cultivate its community, and although there has been substantial turnover, the founders and some core community members remain, and new arrivals have themselves become core community members. Project culture is seen as important and worth effort to maintain and document.

• Has an IRC presence
• Has non-IRC presence
• Has procedures to address non-constructive disruptions in IRC
• Has continuous availability of channel ops (due to freenode best practices, ops do not wear their op hats unless needed, but WE ARE THERE)
• Has cultural documentation
• Has a quotes database
• Notices social problems and works to resolve them

FAIL METER

397 by my count if you try to install it yourself.

It's a miracle this project got off the ground, and installing it for development on your own machine is neither pleasant nor fun. The reality show can be found at qdb.dreamwidth.net.

In the 102 range (THE FAILBOAT HAS ARRIVED) if you use a Dreamhack but prefer mailing lists; 87 (kittens die) if you use a Dreamhack and prefer Dreamwidth communities.

Mitigation: The development community tries to be supportive, especially to beginning developers. Community culture is actively maintained and improved.