echo "hey, it works" > /dev/null

Damien Katz of CouchDB:

We don't want people who tend to ask "How can I contribute? What should I do?". We want people who identify for themselves what needs to be done and how they can contribute, and then do it. Our employees want to contribute to make things better, not for a paycheck, not for validation from a manager or even the community. They do it because they think it will make things better.

Damien Katz: Thoughts on an Open Source Company

He's talking about running a company based on an open source project, but the sentiment is valid for any project. There's a flip side too though; open source projects need to provide a structure where it's clear how people can contribute, make it clear that if you start on X or Y you're not going to tread on someone's toes.

It takes good communication on both sides, project and newcomer.

I've been thinking about diversity in open source communities for a while now. I believe diversity of participants is a real benefit to an open source project, and I think the one community that I'm heavily involved with, Habari, is pretty open and welcoming. For example, you don't have to be a coder to have your contributions recognised in the Habari meritocracy¹.

Right now, we're in the middle of a vote as to whether Habari should adopt a community and diversity statement. Here's the statement in full.

The Habari project is built on the idea that community is more important than code. As such, we, the Habari community, are committed to making you feel welcome.

We welcome people of any ability level, age, gender, race, ethnicity, religious belief, nationality, and sexual orientation. And we welcome ponies.

Members of the community should always treat others with respect, whatever their background or involvement with the project. Everyone is expected to help maintain a welcoming environment. This means not only policing your own actions, but taking responsibility to point out and take action to stop behavior that could be harmful to the community.

Of course, you are free to disagree with opinions and beliefs held by others, but not to be disrespectful towards them because of those opinions and beliefs.

In general, people are in favour, however there have been a couple of dissenters, the gist of the dissent being that such a statement is beyond the scope of an open source project. Several people have responded that when someone does something bad, this sort of statement is a good thing to point to. Rich Bowen has recently written about how open source projects should deal with bad behaviour, and that's worth reading.

But responding to people doing bad things wasn't what prompted me to start (or at least formalise) Habari's discussion on diversity. Rather, I was acting on a feeling that a project that talks about diversity is more likely to attract diverse participants. I don't know of any formal research that supports that feeling, or even much that's informal. If you do know of any, please let me know.²

I'd like to conduct some informal research of my own.

If you're a member of a minority group or a woman (as a minority in IT and FLOSS), are you more likely to become involved in an open source project if there is an upfront statement of diversity?

1. This isn't meant to imply that people in minorities aren't coders, it's just a comparison to some other open source communities that value coding above all else. ↩
2. There has been some investigation of women in IT and FLOSS, but I haven't found anything that measures the outcomes of various approaches to encouraging diversity. ↩

If Blackboard can’t help you fix your problems, you’re out of luck, because nobody understands their code or has the right to look at it. If your Moodle vendor can’t help you, you can go to another vendor, or find another adopting school that knows how to fix the problem. You can also fix it yourself. You don’t have to, but unlike with Blackboard, you can. Likewise, if Blackboard were to go out of business (ask WebCT or ANGEL customers if this sort of thing ever happens), you wouldn’t be able to find somebody else to support and continue to develop your platform. Not true with open source support vendors.

Blackboard’s Response to Open Source: Fear, Uncertainty, Doubt

The lack of support argument gets trotted out so often to attack open source, and it really shits me. You generally have one support option if you're using proprietary software, the vendor. With open source you have at least three types of support; fixing it yourself (by which I mean literally yourself or hiring someone to do it), paying a support company to do it, or relying on the community fix it through normal processes.

I recently submitted a patch to Weka to clean up some code formatting. Unfortunately, I didn't think testing the patch was necessary but the maintainer wrote back to tell me it had failed to apply cleanly, with many chunks failing.

I couldn't work out what the issue was. These were incredibly simple changes, changing mixtures of tabs and spaces for indent to spaces, and removing trailing whitespace (two bugbears of mine). Running patch with the verbose switch didn't tell me anything more about why it was failing.

I popped into #habari IRC, where the friendliest and most helpful people I know hang out. Luke from Squareweave suggested that patch might be confused because there were many small changes in one chunk, close together but not contiguous. Investigation showed that the whitespace changes were a red herring, and that any changes would fail. The individual changes would also apply if patched separately. So Luke was right.

To get around the problem, I reduced the context (the number of lines that surround the change) when creating the patch. This forced many of the changes into their own chunks, and the patch applied cleanly.

svn diff --diff-cmd diff -x "-C 1" > whitespace.diff

Subversion's internal diff tool doesn't allow you to change the amount of context, so I use the diff-cmd switch to use the system diff, and the x switch to pass in the necessary diff parameter.

And now the patch has been applied to Weka.

So what does it feel like to be a woman in open source? Jono Bacon, at the Community Leadership Summit on the weekend, said — addressing the guys in the room — that if you want to know what it’s like to be a woman in open source, go and get your nails done at a salon. He did this a week or so back, and when he walked into the salon he realised he was the only man there, and felt kind of out of place.

Infotropism – Standing out in the crowd: my OSCON keynote

While I'm on the theme of women in open source, this is from Kirrily Robert’s post about her OSCON keynote, which inspired Rich's observation. It's well worth reading (and doing something about).

Well, apparently, when you're a woman, you have to be amazing just to get past all of the old-boys-club and macho chauvinism that pervades the entire Open Source culture.

Women in Open Source - Notes In The Margin

Rich Bowen makes an astute observation about the calibre of women in open source.

Recently, I was complaining on identi.ca about the lack of a PHP 5 wiki.

@michaeltwofish It's just putting words on a frigging Web site. Does it have to use PHP 6.4 (alpha) ?

Andy C

Well, no, I don't need the latest alpha, and it's not just putting words on a web site.

See, here's the problem; editing a wiki is not the same as managing a wiki. If all I had to do was to edit Media Wiki every now and then, I'd probably put up with the things about it that I hate, but the fact is I work on a project that uses a wiki for documentation. As a community, we have to manage that wiki¹. If I didn't hate working with Media Wiki, it would be skinned by now. It wouldn't pointlessly redirect me to a "You have successfully logged in" page. We'd be able to directly export from the wiki to the manual we bundle with the software. You get the picture.

This is what I want from a wiki.

It should be free and open source. I believe in open source software. People should pay at the point of pain, not before they've used the software. If I like it, I'd like to be able to contribute to it. It should be free and open source.

It should be PHP 5. Since Habari is PHP, there's lots of PHP expertise around, making it easier to customise. PHP has its flaws, but PHP 5 is like a ... well, when you compare it to PHP 4 it's like something pretty nice, even if it makes me want to scream at times.

It should have a sensible architecture. This is similar to the PHP 5 thing, since sensible architecture is hard in PHP 4. Unfortunately, stupid architecture is not hard in PHP 5. I'm not saying I'm any good at designing an architecture, of course, but it's more fun to use something that's well designed.

That sensible architecture should let it be flexible and customisable, with themes and plugins. In fact, I'd like the philosophy to be similar to Habari's, small core with easy extensibility.

Can you recommend something that meets all my requirements ? This is not one of those questions at the end of a blog pleading for comments, I really, desperately, would like you to tell me if you know of something suitable for me.

1. Of course, it's not completely up to me what wiki is used for Habari, and even if all my requirements were met, they might not match the requirements of others. ↩

Hearty congratulations to Magento, winner of the best new project award at this year's SourceForge Community Choice awards, as well as all the other winners. It was good fun having Habari nominated.

You should never ever modify core files in WP. If you find you have to, file a ticket for a new hook or filter so your modifications can be a plugin — it makes things so much easier.

• Photo Matt » SecurityFocus SQL Injection Bogus

The security report may well be bogus, and Matt gives some reasonable advice for avoiding security issues, but I think this is a bit rich. Never ever. Emphasised. Okay, go and open a ticket, it will all be fine. I'm fairly sure that the WordPress terms of service (no, no, we're talking about the self-installed software, don't go looking at the WordPress.com terms of service) don't say anything about guaranteeing tickets are addressed in X days. Of course they don't, Automattic is not a support company for self-hosted installs unless you want to pay for "enterprise-level support for large-scale users".

As of this writing there are 944 open tickets, dating back to the start of 2005. Many of those are enhancements, some trivial, some critical. What's going to happen to your ticket? If it's a critical security or data loss issue, it may well get addressed immediately, as I'm sure the original SQL injection attack ticket would have been if there'd been more information, and if it actually exists. Those don't come up very often, and it's likely that it will take a while before your ticket gets addressed. Maybe I'm wrong, and requests for hooks or filters do get addressed immediately, but then you either have to be running out of the subversion trunk or wait for an upgrade anyway.

Now, I am absolutely not criticising the fact that there are lots of open tickets. That's the way things happen in open source software, and to a certain extent it shows the software is a success. But it is unreasonable to suggest that just because you've opened a ticket the problem will go away and you'll never have a reason to change core code.

Chris J. Davis has started working on some image editing software focussing on imagery for the Web. The working title of the project is Simpleshop, because the impetus is the huge number of unused Photoshop features when you only use it for Web images. Knowing Chris, Simpleshop will be a complete misnomer before long and the application will definitely be doing it's own thing rather than simply being a cut-down version of the other 'shop.

Chris will open source the project when he has a working prototype.