The Goldfish Chronicles

Adding to the list, Matt Mullenweg just became a sponsor of the ASF.

As with many of us (especially in the US I suspect), my thoughts at the start of this year turn to the will-it/won’t-it topic of a recession. One of the assumptions of ‘bad times’ is that Open Source will be hurt.

There are two types of Open Source nowadays, there’s money-limited Open Source and time-limited Open Source; the former is most evident in projects that are very strongly backed by commercial companies, whilst the latter is most evident in volunteer projects.

I think it’s going to be true that if there is a recession, that it can hurt the projects which rely on a strong amount of corporate backing; for two separate reasons. The first is the obvious one that will occur if companies realign their foci on a different strategy, lay people off or the money dries up for other things (conference trips, open source company VC etc). The second is going to be the more interesting one, those projects which not only rely on a strong amount of backing, but are also owned by that company, will feel that thumb as it seeks to change the direction of the project. I think that will do more damage than the temporary lack of funds.

Previously you would have thought that Open Source would have hurt less in a recession as frugality becomes more important, but I suspect it’s in so many places that that effect will be less than previously. Plus the company reliant projects are loosely tied to a revenue stream and that frugality will hurt the revenue stream even if it doesn’t hurt the project itself.

A trickier one to consider are the time-limited projects. These, generally volunteer, projects have both pro’s and con’s in a recession. Longer work hours, being out of a job, a general depressed industry will all lead to people having less time to indulge, however those same things will also increase their need to escape, and an evening Open Source project is often more about escaping from the day than it is about repeating the work of the day. In the hunt for jobs, small advantages like project involvement will help resumes stand out and contributors may be less unemployed than non-contributors.

New jobs will also mean new experiences, and such times may imply a greater creativity than a previously steady employment market had led to. People will be forced to think new things and this will lead to new projects.

In summary, this is a tale of the Tortoise and the Hare. Corporate Open Source is high energy, speedy and volatile; while Hobbyist Open Source is slow, steady and stable.

[Don’t take this as a claim that Apache will be fine - many Apache projects get a lot from Corporate Open Source]

ACT 1

“I’d like to try goat milk”, said I to my wife; she being the knower of where to find such things.

ACT 2

“Oh, and I got you some goat milk today”, said wife to I; delivering upon her role as knower and finder of such things.

“*gulp*”, thought I, “over ambitious aiming trips up husband yet again”.

ACT 3.

SCENE 1.

“Cow milk today… don’t want to mess up the Weetabix”, thinks I.

SCENE 2.

“Cow milk again… Weetabix is important”, scurries I, avoiding a decision.

SCENE 3.

“Stop being a weasel”, says some hidden part of my brain that likes to deal out Anglican guilt (like Catholic guilt, but we don’t need the Pope to apply the pressure). “Try the milk”, says Mr Invisible, “you have to”.

“Let’s try this goat milk”, says I, brave in the face of 474 years of independence from Rome. “Nathan, do you want to try it? It’s goat milk. ”

“Yes”, says my son, he whose only fear is going to bed. “Yum”, says my son, he whose taste buds can actually taste rather than sigh longingly back to Szechuan peppercorn stir frys.

So I try it. It’s not bad. It’s not great, but not bad. Well a little odd in the after-taste, kind of sideways creamy. Not bad though.

ACT 4.

“Want some more goat milk Nathan?”, says I, being called back the next day by this novel liquid in the fridge.

“No”, says son, he whose lexicon is simple enough that not mincing words is a necessity not a virtue.

“I do”, says I, and in so doing I pour a glass, and proceed to explain that I’m drinking it to my wife, she who is the knower of these things. “Want to try some?”

“Sure”, she says, brave as only someone without an English primary school dinner education can be. “Tastes goaty” (by which we ascertain it tastes like goat cheese (feta-like), though I suggest it might be that goat cheese can have many tastes in a desperate attempt to deny the possibility of milk ever tasting like cheese [cf: school dinners and subsequent cowardice]).

ACT 5.

While shopping at the local corporate grocery (Fred Meyer, like their owner Kroger but a tiny bit crapper), I notice they a) have goat milk, and b) the low-fat variant is solidly on sale. So I buy it (rule #1 luxuries must be on sale to be bought). Given that the previous normal goat milk had tasted a bit creamy compared to normal cow milk, it’ll be interesting to see how the low-fat milk tastes.

I’ll be the one hoping Nathan is prepared to take the first taste tomorrow.

Noticed something the other day while doing some Commons coding.

While at SourceLabs, I got in the habit of attaching my fixes to the JIRA issues before commiting them. This was for two reasons - first it was intended to be a way to remind myself which issues I worked on in the dayjob and which in the nightjob; and second it made it easier for me to apply them to SourceLabs versions if the upstream version didn’t get released. The first reason didn’t stay true completely as I got used to attaching the patches even in the evening.

What I’ve noticed is that I still do it. Furthermore, others seem to do it too though I’ve no idea if I influenced that, or if it was already going on.

Let’s take a step back and discuss the acronyms in the title.  Apache Projects operate under either Review-Then-Commit (RTC) or Commit-Then-Review (CTR). Generally it seems that CTR is the usual - namely you commit and others are reading your svn commit when it hits the email list. If they disagree, they complain. Some projects use RTC, which is when you discuss the patch and then apply it - usually it seems either because there’s a lot of emotive feeling on the subject and they want to avoid a commit war, or because the code is very stable and they want to keep it so.

Commons uses CTR, or at least it used to. Now, with this trend towards taking patches through the issue tracker for at least some of the components, we’re doing RTC in a CTR environment and ending up with RTCTR. Namely, a subset work on the JIRA issue, reviewing the patch, and then the whole can do review on the commit when it goes in.  ReTraCToR.