The Goldfish Chronicles

Heading off to the Open Source Business Conference (OSBC) soon. Should be interesting, and hopefully I’ll get online and be able to blog a bit.

Just sent out the announcement of the Commons Lang 2.4 release, which eagle-eyed viewers might have noticed sneaking out in the middle of the week.

It’s the first of three releases that I got to work on a lot in the dayjob, last summer at SourceLabs. Someday hopefully I can help get Taglibs Standard 1.1.3 and Quartz 1.6.1 out.

Minor note on how I do my Commons coding now. When time allows, I head over to igoogle.com and look at the front page. I have this configured to show my Google Reader latest on the front page, in which I have JIRA feeds connected [I use Bloglines for reading blogs].

I find this to be the best way to keep up to date with development. Much nicer than watching the emails fly by. A JIRA pain seems to be that new issues and update issues (which means comments usually) appear on different RSS streams. Here, in case it’s of use, are the urls I use:

New issues

Comments

I also monitor Quartz, ASF Infrastructure, osjava.org and sourcelabs.org in the same way. I’ve recently started starring the interesting ones so I can go back to my ‘watch list’.

I remember a while back hearing that the OSI were discussing how they could start encouraging a reduction in the number of Open Source licenses. It looks like a little came from it, but not as much as might be hoped. Elsewhere, Google.Code only offers a small number of licenses, SF.net rather offers a category of license in their metadata; which is probably how Google’s attempt to encourage reduction ended up. Trying to help put together Apache’s opinions on license compatibility gets you wondering how many licenses we really need?

First, it’s obvious we need a permissive, a weak-copyleft, a copyleft and a network copyleft. So 4 licenses would appear to be our minimum right now. Going by popularity, that’s going to be BSD, LGPL 2.1, GPL 2.0 and AGPL 3.0 (for want of many in that category). We’ll also still keep public-domain statements, so thats 5 ‘licenses’, where people also might want to use MIT.

Using the old versions is a bit silly though. So obviously you’d add GPL 3.0 to the list instead of GPL 2.0; but then after an argument GPL 2.0 would have to come back because some people aren’t moving (yet?). Wheee. BSD needs to be kicked out due to all the hacking around with the license [I mean James/Bob….WTF is with “Do no Evil?”, c’mon]. So I’ll push AL 2.0 through there as the better choice because it’s not a template license and doesn’t encourage people to hack around with it.

Lastly we have the weak-copyleft space. Here we have three major trees - LGPL, MPL and CPL. MPL has the best community feel in my view - the most independent, which I feel is a huge part of standardizing licenses, not having them owned by a for profit company. So MPL (I assume the .org owns it), EPL and LGPL good, CPL and CDDL ‘bad’. Which is a shame as I hear CDDL is the ‘best’ version of the MPL tree. In my view MPL would be the best to end up on, and get ‘fixes’ applied.

So we now have:

• Minimal: MIT.
• Permissive: AL 2.0.
• Weak copyleft: MPL.
• Strong copyleft: GPL 3.0.
• Network copyleft: AGPL 3.0.

The arguments being to get LGPL dropped in favour of MPL, getting MPL ‘improved’ to let CDDL + EPL fold in, and convincing people to drop BSD type licenses in favour of either choosing AL 2.0 or MIT. Then you’ve got to convince people using the Artistic license to drop that and pick one, and the Ruby guys to drop their custom license and pick one [hard coding the language implementation names in the license - nice one]. Getting the *BSDs to change seems unlikely eh? and we all know that the Linux core is not moving GPL v3 wards anytime soon.

Then we have the new Microsoft licenses. MsPL is nicely written, but is from a for-profit. MsRL I need to read more to realize whether it’s weak-copyleft or not; but it’s still from a for-profit.

So - given the plethora of options at the core of the Open Source license world, what’s going to stop the other licenses from wanting their own place in the sun? We need the big licenses to make some strong steps (and swallow their egos and pride) and move towards each other if proliferation is such a big deal. Weak copyleft is the biggest area for needing merger; with the permissive BSD/Apache problem also needing solving.

Not going to happen is it

I’ve seen it said a few times that Google Summer of Code is a recruiting effort and we should not be happy that they do it. Most recently was on a slashdot thread [okay - I suspect you could find any statement you want on some slashdot thread or other - a kind of inverse monkey+typewriter system], and said thread kicked this blog entry out of my head and into the ether where blog entries sit while I find time to write them.

I suspect that the statement is pretty true - GSOC and Recruiting. It helps them recruit. It also builds some goodwill. It makes Open Source projects better by having more code being done and I’m sure Google use some of it. All of this is true. Don’t worry about whether you should be thankful or not for all of that. Here’s why GSOC is a good thing.

Users aren’t the most important thing to an Open Source project; and neither is code being written. The constrained resource for the vast majority of Open Source project is contributor time; and the chief method of getting more contributor time is to get more contributors. More employees if you will.

This is the best thing that GSOC does. It does potential recruiting for Google sure - but it also does recruiting for Open Source projects. We don’t want companies to dump code on us, we want people to join in with the work. Recruiting is why the common answer to a request for enhancement in Open Source is “Got patch?”.

The deal, as such, with Google is that we, the Open Source world, do their prescreening in return for getting new recruits. There’s an additional benefit for us too. Before they join Google (or other company of your choice), they pick up the Open meme.

Bwahaha etc.

Just a note that I liked this picture on Wikipedia:

Seems the Beeb isn’t immune to the easy road of a tabloid headline:

Pompey locals show Dunkirk spirit

Pulling Dunkirk out of the hat seems a classic line of journalism. However, I can’t help but think:

“What, they got in their boats and sailed to France?”

Suggestion of pledging allegiance to the Queen when you leave school at the beeb. What an utterly stupid idea. People are seeming less ‘British’, so let’s make them swear by “King and Country” and suddenly we’ll be back in good old 1908. Plus, at 16 to 18, school leavers are at just that impressionable age when they are so likely to be in favour of the idea. *boggle*

Fortunately there are lots of soundbytes against it, so presumably this is non-news. Someone showing that they haven’t been wasting their time, but, ‘oh, no one seems to like it’. Seems like you could get a consensus from random people in the street that it’s a dumb idea.

I continue to grapple with the concept of how to treat users of Open Source projects. Should you be cruel, or kind?

It sounds like a dumb question - rude hackers who rip users apart for daring to ask a question in a not perfect way are just arseholes who need to get off their high horse. Right?

I’m not convinced. And I’m someone who usually over worries about being polite. Mostly because the voice inside my head is, I suspect, the kind of stormtrooper who after the Death Star blows up for the second time, will be found out of uniform at the Rebel party selling little burgers of ‘forest meat - mind the blaster marks on the fur’.

Anyway, the question about whether you are cruel or kind is linked in to the required resource on your project.

A project that is not widely successful yet (notice how my polite overmind changed ‘a useless project’ into something rosy and smelling of fluffy bunnies) needs, first and foremost, users. Preferably users who ask questions and raise bug reports. This project needs to be nice to their users, pamper them, get bugfixes back out quickly, grow in user base and bug reports.

The alternative is a successful project, a project that has spread like a virus through the grass roots and up the trees of corporate computing to the point where even the CEO of the company could guess that the company might use that product. In that case, the constrained resource is not users, they’re falling out of the trees. Instead the project needs contributors; committers; leaders. Being kind is not the classic way to create these wee beasties, instead you have to put your BOFH hats on, roll up your sleeves to expose your clue-sticks and get ego bashing. It’s the classic mentoring method, usually involving reducing your recruits down to their constituent parts and then building them up again. It works. Casualties are expected.

There are two paths to choose, and I’ve described the happy direction in both. Let’s cover the “Oh No” direction now.

If you are a pathetic little piddly project with crap all hope of going anywhere (help, where’s the polite censor??), and you treat your users like, well, little fluffy lambs - they’re going to remain as little fluffy lambs. As little fluffy lambs are wont to do, they’ll go off engaging in grass root discussions and your project will spread like wildfire. Or maybe like a small spark in a refuse tip, quick sometimes, but other times it gets to the tyres and smoulders and smells for months. Point being - your lambs never step up.

If you are a well known project, full of arseholes who think they’re God’s gift to the ego; and you treat your users like, well, goats in training - you’re going to have a high attrition. You don’t really care as long as you get some goats, but for many of us, especially those of us in baabaa suits, there’s got to be a catch. I continue to believe that there is - that the stink travels and your well known project’s products will start to get a bad name, losing you users. If you look at the way it seems to work - the users you seem to lose are noticeably the potential goats. I’m not sure why - maybe it’s just because no one notices users leaving, but when contributors start leaping ship into a competitive product, that’s noticeable.

This may all sound rather familiar - I refer you to the goats/sheep matrix. Thinking of sheep as ‘potential user’ and goats as ‘potential contributor’ might be a better way to view it.

The question is…. how to balance the two?

There’s an easy answer with regards to mailing lists. Treat your users@ list like users, and your developer list like trainee developers. Phrased like that, it sounds pretty damn obvious.

The harder one seems to be how to handle your issue tracker. I’ve seen users bludgeoned to death on these while I was monitoring a lot of them in my SourceLabs days, and it’s obvious there’s a problem. I think the answer is still staring us in th face.

• Treat the bug reports as users. Be kind to the fluffy user. You want more bug reports. Fix those bugs.
• Treat enhancements and new features as noise. Ask for a patch.
• Once you have a patch, pull out that clue stick and pound away. These users are self selecting themselves as potential contributors and if you lose them as users while trying to pound them into contributors, then it’s not a huge loss to your user list.
• Keep a good eye out for contributors who are experienced at contributing already - treating these people like newbies will backfire. Expect more from them and nudge them when they are not getting your community.

Following up on a previous post; here are pictures of my son and I having fun at Jump Planet: http://blog.rocketbutt.com/roller/boo/entry/bouncy-castles