The Goldfish Chronicles

One feature from Roller that I really miss is the ability to have only the most recent entries open for comments. After dealing with lots of spam, I finally put together a solution. It’s very low tech; I run the following in a crontab for each blog:

echo "update wp_2_posts set comment_status = 'closed' where comment_status = 'open' and post_modified < date_sub(curdate(), interval 14 day) and post_status = 'publish' and post_type='post';" | mysql --user=xxxx --password=xxxx wordpress

Google’s, HP’s, Covalent’s, Tetsuya’s bitch.

A colleague sent this blog entry from Matt Asay around at work. It was interesting reading, but with poor conclusions.

Matt says that “developer communities are great for developers, and not so great for anyone outside them”. That’s wrong, instead it’s “communities are great for members of the community, and not so great for anyone outside them”. Well that’s a shock Matt’s revelation is in fact a piece of circular logic.

It hits again when Matt says “if you already know your way around the code of Debian or Apache, you’re more likely to get a response”. Again wrong - “if you are a member of the community, you are more likely to get a response”. Again, big shock and some circular logic revealed.

He talks about 99.999999% of the world not being developers (or community members as he should have said), and that again is a crap piece of text. Any attempt to use ‘the world’ is useless as the majority of the world lack a computer. The number who use MuleSource/JasperSoft/SugarCRM is tiny tiny, and the number of those who have the money to pay for paid support is smaller. So what was the point of that paragraph? Strike it from the record. Except…

Except community isn’t just a singleton. There’s the dev list, there’s the user list, there’s the forum at some website out there (codeguru etc) which has sprung up for extended users, there’s the mailing list at a large corporate where people gripe about a project and share info, there’s the wiki page at your own workplace. This is all community support, and this is what Matt is really attempting to target with his ‘paid better than free’. In the end, paid vs community is not about being able to get an answer from the community, but being able to demand an answer from the paid support. It’s about SLAs, and if you demand that SLA, then you should be paying. Otherwise, join a community.

To put it simpler - if something is business critical, don’t rely on the community. Rely on a business. Now go figure out what’s critical.

The one thing I liked about the report was that the paper Matt quotes chose to hold the Apache HTTP Server project up as a failing community support example. Should be interesting hearing their views on that one.

(I’ll use a different blog entry to talk about the underlying paper)

Akin to a previous post, this is a thought dump on something that comes up while looking at project reports in the ASF board meeting.

Sometimes a project will report that they had a face to face meeting, or are planning one, and the immediate concern will be whether they are organizing it openly. Face to face meetings are hugely valuable (thus the emphasis the foundation puts on the ApacheCon conferences), but making sure that all of the contributors are aware of the meeting is  also important. Discuss the plans for the meeting on the dev@ mailing list; make sure that contributors are welcome to attend if they can.

One worry might be how to refuse those of trollish behaviour. I think it helps that it’s a lot, lot harder to be a troll in a face to face meeting. The author of the BileBlog attended the Struts/WebWork BOF (birds of a feather) a few years back and it didn’t turn into a bile ridden criticism of all the things they’re doing wrong. Most likely your favourite troll won’t show, will be quiet, or even better - will be valuable.

Another worry might be that the discussion will be all about user questions and not development discussion. You should be so lucky. If that turns out to be the case, embrace it and set aside part of the meeting for that focus (a third or so perhaps).

As with all of these thought dumps (and I hope to do a lot more), this is what I’ve culled from the information flying by within Apache - it may not be 100% the answer.

Last night I released 2.4 of the Release Status plugin. It continues to be a lot of fun, and user responses on the Atlassian plugin page continue to drive bugfixes. New features were added too.

A couple of new symbols were added to show that you’ve either missed a deadline or completed all your issues - they immediately proved useful as I spent Friday getting to 100% on my work workload just to see the and do my part to avoid the .

It adds the ability to show a random project - this will be a nice one to put on the Apache front page I think. The only oddity is that sometimes it vanishes when it hits a project that has no versions. Lastly it adds an adaptive mode for the currentuser/alluser toggle. Early in the project it uses alluser, as it gets passed 50% it switches to currentuser to get over the hump, and then as it hits 95% it switches back to alluser to tie up the loose ends. I suspect the inexpertly chosen numbers will need tweaking.

Fun, fun, fun.

Pretty chuffed - here are the downloads for my JIRA plugins since 13th June when it moved to a dedicated sourcelabs.org machine, so the last 6 weeks. Ignoring the office IP address.

223 - releasestatus
139 - filterlist
111 - currentuser
78 - projectlist
61 - search
59 - contribution-report
48 - poll
40 - html
7 - sandbox