Archive for the ‘Opinion’ Category

AL 2.0 / GPLv2 clash

Tuesday, March 25th, 2008

This came up a couple of times here at OSBC, not overblown but mentioned. It’s a bit painful to hear Legal people worrying about something that doesn’t feel like it should be a huge deal.

Then I noticed Alfresco’s nice FAQ entry on this:

<a href=”http://www.alfresco.com/legal/licensing/faq/#faq6″>FAQ #6</a>

Future of Open Source [panel]

Tuesday, March 25th, 2008

Panel of people with big thoughts on the future of our beloved open world. Roger Burkhardt (Ingres), MySQL (Zach Urloff stood in for the ill Marten Mickos), John Roberts (SugarCRM), Jeff Whatcott (Acquia (Drupal company)) and Mark Shuttleworth (Ubuntu).  Chaired by Michael Skok.

A somewhat interesting session, it went over the survey from before the conference and asked the panelists if they agreed with those surveyed. Very good way to model a panel session. I remember Mark Shuttleworth speaking at ApacheCon and not being very impressed simply because his focus (Linux/Desktops) was not a good fit for our general focus. Mark was very impressive on this panel - his comments were at the right time, applied to the right place etc, and always very good.

Of course there were bits I disagreed with - one day it would be interesting to do one of these panel things where I would feel the urge to get up there and speak my mind. Generally too English (polite… timid… quiet… whatever) to argue with them.

One of my disagreements is on a question as to whether Open Source is:

a) Business Model

b) Marketing Model

c) Development Model

d) All of the above

e) None of the above

The true answer is f) Community model. Wikipedia is a great Open Source success story. a), b) and c) are all true when you realize they are on top of a community model. As someone at lunch pointed out - very Cathedral & Bazaar; or Cluetrain as I pointed out. Open Source is a business model in that it’s a community model, communities are about conversations, and business is at the end of the day about a conversation in which defined value is exchanged.
While talking about the effect of Open Source on the economy, a very good point from the Jeff Whatcott - “Absence of money is a bigger push for innovation than lots of money”.

A couple of t-shirt ideas:

* “Open Source is People”

* “Open Source was Social 1.0″ (or maybe 1.5?)

Mark Shuttleworth asked a good question. Have we reached the IBM point yet? Is Open Source usage the default answer now and you have to justify not choosing that? Opinion was divided on whether we’ve reached that yet.

Creative play…

Tuesday, March 25th, 2008

Sounds like Carrie is having fun with Nathan: Thinking on Creative Play.

I’m very happy with the lad. As Carrie explains, creative play applies to anything.

Personally I like to take a chunk of the credit for when I taught N to lie/make a joke. In classic Red Dwarf style one night, I held up a teddy bear and said “Banana”. He cackled. A few days later he started to do it too, understanding the hilarity in calling a teddy bear an elephant.

Creative play is inside the mind, not inside the toybox.

OSBC#1

Tuesday, March 25th, 2008

Awake. Breakfast. A price that only hotels can charge.

Registration. Bag, spam filled, but will probably prove useful once it gets home as conference bags usually do. We use ApacheCon bags to pack our shopping, and an EclipseCon bag will probably be my hospital bag.

Speaking of, fingers crossed everyone that nothing happens back home btw. Repeat the mantra… “Hang on, hang on, hang on”.

One item of note in the bag, a last minute addition of a presentation on “Can Open Source communities survive acquisitions and mergers”.  That’s an interesting topic nowadays, so suspect I’ll head along.

Nice. “Video Killed the Radio Star” just came on - but some idiot has the bass turned way up and the initial drums sounded like a brachiosaurus farting.

Solving license proliferation

Wednesday, March 19th, 2008

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 :)

Google Summer of Code -> Recruiting for Open Source

Friday, March 14th, 2008

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.

Union Jack make up picture

Tuesday, March 11th, 2008

Just a note that I liked this picture on Wikipedia:

Old chestnut of English journalism

Tuesday, March 11th, 2008

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?”

Pledging allegiance in the UK

Tuesday, March 11th, 2008

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.

Open Source recruiting: Users vs Committers

Monday, March 10th, 2008

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.