Older blog entries for bwh (starting at number 8)

Wikipedia

Larry Sanger wrote a history of Wikipedia on Slashdot today. Interesting insights into the origins of the project.

One point that Larry hit on that I've also come to conclude after a variety of open source projects:

Wikipedia became what it is today because... we proceeded to make a series of free decisions that determined the policy of the project and culture of its supporting community. Wikipedia's system is neither the only way to run a wiki, nor the only way to run an open content encyclopedia. Its particular conjunction of policies is in no way natural, "organic," or necessary. It is instead artificial, a result of a series of free choices, and we could have chosen differently in many cases.

All too often, I find that people look at Open Source, and see all manner of benefits and cool aspects and whatnot, but totally miss or dismiss the culture. They focus on the people, or the procedures, or the technology, or whatever, but completely ignore the sociological aspects. I find this extremely ironic, because in my mind the culture is the most important thing.

People have been working together for noble purposes since time immemorial. Sometimes they do it for money, sometimes because they don't have any other choice, but occasionally it's just because they *want* to. People see that it's possible, and for whatever reason (belief, need, obsession...) are self-motivated to work on it. Maybe it's standing impossibly huge rocks on their ends in a big circle, or maybe it's writing a complete encyclopedia of everything in the world translated into a bunch of languages and distributed everywhere across the planet.

Anyway, for whatever the cause, you've got a bunch of people compelled to work together. One might assume that the cause is enough, and that *poof* everything else just magically falls into place inevitably. Out pops a successful project.

Nope. Doesn't work like that. Good ideas are cheap. Noble causes are many. The plain fact is that by and large people are ornery, irritating, opinionated sots who'll argue the sun should set in the east, given the chance. What you need to make the whole thing go are a set of working principles and rules of thumb for how to work together. In other words, they need a culture.

You need some basic stuff. What are the primary ways we should communicate with each other - IRC? Email? Powerpoint? Song and dance? How do we organize our outputs - milestones on a Gantt chart? Weekly releases? When there's enough features? What is our overall mission - to make a complete encyclopedia? To make an editor that implements the complete SVG spec? To create a world dominant operating system?

Then you also need a whole host of more intricate interpersonal rules. How are stupid questions handled - answered? ignored? flamed into oblivion? How are decisions achieved - by fiat of The Leader? by group concensus? by technical merit? by first-come-first-served? How is off-topic discussion accepted/handled? How are disagreements resolved? How are plans made? How are bugs/problems tracked? How is knowledge shared from person to person?

Like Larry points out, I've also noticed that a lot of these things get solidified pretty early on in a project. Right at the beginning of a project the rules are extremely informal and anarchical.

I think our society likes to simplify things down to a single root cause for everything, but for many things it's not so simple and really depends on a lot of different factors. Open Source projects are one of these things; establishing an effective community is hard and depends on a lot of different things. A good idea, plus good people, plus good processes, plus a good culture, plus good timing and a little luck... Miss any one of those and you're sunk.

When we started Inkscape, I had a lot of the above philosophy in mind. I knew we'd have one shot at establishing a good culture and wanted to make the best of it. We quite deliberately set up processes for handling bugs, social guidelines for getting along, rules for how releases are done, and so forth, that were ingrained in the community and remain to this day. Because of this, we've avoided a lot of the typical problems of many projects: We've had very little developer burnout for as much growth as we've seen, our users have been universally appreciative and supportive, progress has been steady, and we've had relatively few flamewars.

I'm pretty proud of how things turned out; I'm certainly far from the most knowledgeable or prolific coder, but I feel that the work I put in early on to try to help set the tone for the project's culture has paid off many times over. Today we have a project where knowledgeable and prolific coders feel comfortable working together making a great program.

Inkscape

Posted the status report. Bugs me that SourceForge's status are *still* AWOL. Ah well, I'm sure there's a good reason.

We've also been approached by a German magazine 'COMPUTERBILD' to include Inkscape on their monthly magazine CD. Rather odd, since from what I understand, the magazine is one of those Windows commercialware type publications, but maybe Open Source is starting to make penetration there? Dunno, but there's some worry on the Inkscape list that our 0.41 release needs a bit more polish, since we've found some minor but highly annoying flaws since the release. I tend to agree, but am too short of time; maybe someone will do a point release.

Task Manager

As if I didn't have enough to do, I've been mulling over some ideas I've banged around for years about doing a task manager. I get pretty obsessive over planning out tasks and such, but do it pretty much manually, with plain text files. It seems like an ideal sort of thing to do with software, but I've never seen anything that captures the workflow and metadata the way I think it should.

For example, these days there's a lot of interesting local political initiatives and actions, like stopping $BigEvilCorp from doing $SomeEvilPlan or whatnot, that I'd love to help, but they don't have many options for how to participate. Either donate money, or commit a huge amount of time doing tasks I'm probably not going to be very interested in.

What I would love to see is a Wiki-like thingee that states the high level objective, and allows the tasks to get identified, elaborated on, performed, reviewed, etc. in a distributed fashion. Thus, instead of collaborating on an encyclopedia article, the community would be collaborating on writing todo lists.

I poked over ideas the other night with Mike Day about this. There's a lot of architectural questions - what kind of interface(s) would it have? Would it store into a relational database or XML files in a dir structure? Would it be written in Perl, or C/C++, or some fancier language?

When I was only half-woken up this morning, my brain accidentally merged this into my 'dms' project design, and I realized that maybe the task manager could be implemented as a special case of the document manager. Both systems involve Objects (Tasks or Documents) with various Properties, that can exist in various States in a WorkFlow, that have Relationships to other Objects. Both systems need to enable communities to do online editing of all this info... Hmm...

Golf

Today was our golf day at work. Even Linus came out to join us. Last year my team came in first, this year last. Was a great day to be outside; finally the rain's given way to some sun.

NFSv4

Today we did some crosspollenation between the NFSv4 group and the OSDL Security SIG group. NFSv4's big change from NFSv3 is its new security capabilities, so we are attempting to gain some guidance from the Security SIG about how we should go about testing/proofing it.

Also, Lynn and I have written an article for LinuxWorld Magazine, that will be the cover story for May. The article discusses how we're organizing the testing efforts, and emphasizing community-oriented structures. It sounds like due to how well NFSv4 has been going, that others will want to use it as a model for how to do other OSDL / community efforts, so I'm hoping this article helps give some ideas on good ways to mesh corporate and community structures together.

March Madness

I wrote up a short piece for Advogoto the other day, Anger Online. I have absolutely no data to back it up, but I make the case that March is the hardest month for Open Source projects (with Oct/Nov being the best). I've always wanted to figure out some way of measuring it, but never got a round tuit. Maybe someone can take the idea and run with it, and do some plots and see if there's any sense to it. ;-)

I the gtkmmification work for Inkscape. I've been slowly plugging away at it; my goal is to get the Inkscape canvas working properly within the new Gtkmm chrome. I also posted a Donation system proposal. Basically, use the donations we've been getting to help fund development of the file format converters.

Watched 'The Corporation' last night. Wow. Definitely worth adding to your NetFlix list. :-)

A bunch of us Inkscapers are setting up blogs and rss feeds and such, so I figured I'd be lazy and just dust off my advogato account. ;-)

Just to catch my diary up to date... I decided my fate in life was to become an Open Source developer and help organize Open Source projects like WorldForge. So, I moved up to Portland and as my contract with Morgan Stanley ended I switched over to the newly formed "Open Source Development Labs" (OSDL) in spring 2001. I focused first on helping assemble the company's infrstructure, databases, services, etc. but last year moved into a Performance Engineering role, where I help work to improve open source software through testing.

Meanwhile, I got burnt out of doing coordination for WorldForge and got involved with Gnupedia/Nupedia, which were aimed at creating an online, Open Source style encyclopedia, but weren't quite working. Several of us then started trying doing this using wiki software, and *that* worked well. Thus Wikipedia was born. :-)

But I got tired of arguing with folks on Wikipedia, and wanted to get back into something coding-oriented anyway, and so joined another project called Sodipodi. After a while it looked like we could really turn it into an open community-oriented project like WorldForge had been, but that approach didn't really jibe with the Sodipodi structure, so instead several of us struck out on our own and formed a new project called Inkscape.

Since I absolutely cannot draw, I helped form another project called the Open Clip Art Library, to help skilled artists help the rest of us. We have a monthly release schedule, and are included in several Linux distros.

At work, my most recent project is organizing an effort to test the Linux NFSv4 kernel code. NFSv4 marks a major change from NFSv3 in that it adds 'state' tracking, security, and integrated caching. NFSv3 has always been infamous for its insecurity; it's lack of state awareness has also led to some inherent performance limitations that had been preventing its use for a number of important applications. Thus, there's some major benefits to NFSv4 that people are looking forward to.

However, the challenge is that switching to NFSv4 is going to be a pretty intensive change for end-user companies; they have to weigh the benefits against the risk of bugs, downtime, and the normal frustrations of new code. Thus, the name of the game here is Testing. If we can test the heck out of NFSv4, we can both eliminate problems and give users quantification of its stability and benefits. We want to prove that it's safe to migrate to, and if it isn't safe, we want to fix it so that it is.

The way I'm going to try to achieve this is to build up an open source style community engaged in testing of it, like I've done before. The thing that will be interesting about this is that it's much more corporate focused. However, my intuition says that the same techniques for building an open source project for games/drawing applications/encyclopedias can be adapted for building one around network file systems. So far so good; we've got half a dozen companies committed to working on it, and we're well organized to include more.

Today I elaborated a bit on WorldForge's Goals.

There was a bit of an interesting discussion on the WorldForge mailing lists today regarding allowance of proprietary modules and our game server. On the side of the "commercial user" it was emphasized that they'd be really "put out" if they couldn't link in proprietary modules to the GPL'd code. On the Free side, it was felt that this would be Bad for freedom. If a binary-only, semi-free module exists, this is a disincentive for others to create completely free modules for those purposes. Personally, I ask simply what benefit WorldForge could possibly derive from the existance of people with closed source code modules? If we can't use the code, then what good have we obtained? We don't have a "bottom line" or investors or a PR image to maintain or anything like that to worry about; our existance is already solid and not in any way dependent on any other group's opinion or need of us.

WorldForge's charter is to promote Free Gaming. Allowing closed-source, proprietary additions to our Free software works contrary to that goal. I can't see how it is in our interest to allow this.

Mithro put it very plainly: "Commercial support is good in some ways, but commercial support where they aren't releasing code isn't good for anyone. And we arn't here to write software for companies..."

"Ensuring our corporate partners are able to maximize their profit from use of WorldForge software" is NOT in the WorldForge charter. And I guess I find it odd that people keep assuming that it is. Making money is fine. And if someone is doing some service so hard to get freely that people will pay for it, that's _great_! But gaining a monopolistic stranglehold on players through secret-keeping is *exactly* what we're trying to change!

*Sigh*

Most of the weekend was spent adding stuff to the Free Book Project's website, and working on that book. (freebooks.myip.org). Today I wrote a longish piece on collaboration in net projects... I'd love to get feedback or insights from others interested in this subject.

On WorldForge we finally named a new official infrastructure coordinator, Peregrine! So we should hopefully be seeing some new initiatives taken in getting WF's services better organized. Also, it sounds like malcolm is making great strides in getting the client ported to Windows, and a LOT of people will be happy when that comes to be.

More personally... I'm going to finally be moving back to Portland in a few weeks! I had decided to leave my job in order to do this, but my boss decided they wanted me badly enough that they'd let me telecommute. :-) It's nice being so needed.

Novalis wrote in his diary:

At any rate, my laziness w.r.t. fonts has lead me to the following conclusion: All media must have author info embedded in it. MP3s do (I try to set my ID3s). There's no excuse for other stuff not to. People are otherwise too lazy to do attribution right. Throw in a Paypal ID, and you've got a street-performer mini-economy. I think this is mandatory.

Wow, the exact same thing has occurred to me in the past when fiddling with fonts. And I agree that pretty much every piece of media (heck, software too), needs to have the equivalent of an "About box". What's the license, who made it, where can support be obtained (if any), and so forth.

Once, back when I was a propulsion engineer and still uncertain of what I should do with my life, I got the following message in a fortune cookie, in a tiny Vietnamese restaraunt in dusty Los Angeles about three years ago (i.e., 1998):

Depart not from the path which fate has you assigned.

Fortune cookie messages are usually too trite to be profound, but something about this struck my fancy and I put it in my wallet. I run across it every now and then when going through my wallet, and think on it. When I got it, I had no idea what it meant. How does one tell what one's fate *is*, anyway?

I considered my past... I had spent a considerable amount of my youth in Boy Scouts and had developed a bit of a talent for leadership, yet detested the idea of corporate management. I had played and created roleplaying games since age ten. I had been programming computers since age eleven. And I loved working with people through the Internet. Presently, I was attempting to make a career as a rocket scientist, but juding from the state of the industry, Fate was certainly not favoring it.

And I had just recently gotten involved with the WorldForge project, and somehow (fatefully?) been selected to be its coordinator.

I decided that maybe, just maybe, this was my fate. Not a bad fate, as fates go. Actually, a pretty cool one.

But _how_? While Game Programmer is a valid career path, Open Source Game Programmer most certainly ain't. If this were my fate, it was anything but obvious how to get there...

I like Chinese food, and so I guess it was inevitable that eventually I would run across another "profound" fortune. A year and a half later I did:

Your success in life must be earned with earnest efforts."

Okay, wow. earnest. Hmm. "A serious and intent mental state." One must be serious and think very hard in order to achieve one's goals.

I decided to end my career as a spacecraft propulsion systems engineer, and to go into computer programming. I figure, in order to achieve my fate, I will need to gradually shift my career towards something more conducive to work on WorldForge. How I get there isn't totally clear to me, but at least I know roughly where I'm headed.

Today I'm working in San Francisco as a web programming contractor. It's just a temporary job, though; just a stepping stone on the way. It pays well but I couldn't call it a "career". It just pays the bills to support my work with WorldForge.

And the past few months have seen a great deal of progress with WorldForge. Today I built a page summarizing this progress, so shan't reiterate.

One of the people on the project proposed using Advogato to make diary notes about our status. And so I am following the path.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!