And the winner is… the Apache License!

Hell must be a jolly bone-chilling place today, as Matt Asay himself causes quite a stir on Twitter and the blogosphere by arguing that Apache [is] better than GPL for open-source business.

It’s good to see Matt, a long time GPL die-hard, considering switching sides. I can’t resist, however, noting how I happen to disagree. Or, actually, to just partially and conditionally agree.

I contend (and teach, and consult) that a license is only a tool and, as a former colleague of mine (and now Matt’s) likes to say, “a fool with a tool is still a fool”. As a tool, a license serves an ultimate purpose which might or might not be what the original creator designed it for. In the past few years, the so-called Commercial Open Source has butchered the GPL spirit, forgetting about how it was originally meant to set the software free forever and using it to ensure the biggest possible grasp and control over IP that Open Source could provide. As such, the GPL has become the ultimate stronghold against appropriation from third parties – something to make VCs happy, or a way to guarantee that the “vendor” was to remain in the driving seat.

Guess what? The GPL works fine, but with notable side effects that are ultimately business-unfriendly. Back to the tool metaphor, you can definitely turn a screw with a pocket knife, yet that would be suboptimal at best and dangerous at worst: using the GPL as a protection mechanism kinda works at the beginning, yet falls short in the long run. My few faithful readers already know where I’m getting to: there is little to no point in open source without a Community (note the capital C, which means a community of committed people who feel ownership and pride in a project), and you don’t build a community with a license that is actually used to disallow collaboration, as people know they are playing with a ball which isn’t theirs and could be taken away any minute (yes, there is the right to fork: point noted, yet mostly as irrelevant as vTiger and Unbreakable Linux).

The Apache License is definitely better yet it’s still just a tool: there is little point in giving your software away in the most liberal possible way if you are not ready to reap the rewards by building a successful ecosystem around it, which requires much more than a change of license. Moving to the Apache License (or anything in between – I happen to think that the EPL works almost just as fine) is a great first step towards greater adoption and an extended and sustainable ecosystem based on Open Development, but it requires some serious follow up in terms of community building. Take the license alone, and all you have is a different piece of legal gibberish.

Whenever customers confront me with the issue of choosing a license, I feel obligated to enter lawyer mode and start my answer with “it depends”. Neither the GPL, the EPL or the AL are jacks of all trades: what kind of screw do you want to turn?

Of Oracle, Sun and Open Development

Time for shivers in IT as the big news of Oracle buying Sun is more than likely to have someone worried. It’s too early to know whether Oracle will disembowel Sun and sell its mortal remains, butcher MySQL into Oracle CE (Children Edition, that is) or just see the light and do something truly innovative, yet I’m sure there are a few of those “good riddance Oracle, hello MySQL” corporate players who thought the Oracle sales man was gone for good, and who could really do without him reappearing fresh from a new tooth-sharpening session, and ready to chew IT budgets to shreds.

My sympathy goes to all of them who fell into (yet another) Commercial Open Source trap: the lesson is potentially hard indeed, but it could be argued it’s well deserved. Companies are bought and sold all the time, and it would have been nothing short of myopic to ignore that Sun (and henceforth MySQL) was ripe for acquisition, with Oracle being a potential buyer. All of a sudden, corporate eggs are likely to need the same old, worn-out and horrendously expensive data basket anyways, and that will not feel good to many out there. Yet, they could and should have seen it coming or at least account for it.

I’m sure someone will note that even in the worst case scenario of Oracle ditching MySQL, there is still the right to fork and all the Free Software mumbo-jumbo (MySQL will always remain free, anyone can innovate on top of it, yadda-yadda). The sad truth is that forking is an extreme measure, and extreme measures are, well, extremes and difficult to undertake. And let’s not forget how the GPL in this cases tends to turn into Saturn’s child-eating mode, as it makes extremely hard to gather a successful and diverse community: when there is no motivation to contribute except from freedom for freedom sake, there is no way to build a community that cares for something more than freedom itself. Also, I can hardly imagine anyone building a real commercial alternative to now-Oracle’s MySQL: with Larry Ellison owning and controlling the IP in such a strict way, why should anyone but long-tailish small shops take such a huge risk with very little reward? It’s likely that the answer is “no one”, unless some big guy wants to return Oracle the “Unbreakable Linux” favor – and fail at it, of course.

As I pointed out in the past (ironically, in a conversation with MySQL), diversity matters: if MySQL was a project governed by a neutral and diverse community, with a liberal license taking commercial interests into account, we might have seen a different story today. Maybe this is an opportunity for more open (and sustainable!) alternatives such as PostgreSQL to shine despite being constantly ignored by analysts and press? Maybe next time corporate buyers will take sustainability and open development into account instead than focusing on Open Source smoke and mirrors? Or, at a very least, understand that the Open Source vendor they are dealing with is on the market and likely to be ripe for an acquisition by God knows who, and plan accordingly? Maybe analysts will finally understand that the Open Core module is just a remix on stuff companies around established communities such as Apache have been doing for ages, but without the sustainable bit coming from healthy communities? Or will we just chug along, waiting for the next rude awakening?

Unfortunately, I’m afraid I know the answer.

Open Source and Agile – oil and water?

My $DEITY, BarCamps are fun! I spent a great Sunday in Oxford, together with a bunch of fellow Apache-ans and my new colleague: the venue exceeded my expectations by far, with loads of informative content, great fun and amazing views of Oxford during the post-lunch walkabout.

I took the liberty to set up a session to talk about Open Source and Agility, which was actually a lame excuse to drag Marco to the stage and see if we could make sense of what seems to be a conundrum where Agilists and Open Source developers share the same values of openness, transparency and technical merit, yet we don’t seem to be able to come up with a way of working together (as in running Open Source communities with Agile practices, or opening up Agile teams to Open Development processes).

I used to blame Agilists for that, as their strong position on classical unities seems to be one of the major blockers: as long as the team has to be co-located, there goes your clash with any Open Source development model. Co-location has also been a major pet peeve of yours truly, as I believe it’s a model that doesn’t scale and is not fit to today’s work environments who are clearly moving towards asynchronous and disperse teamwork. Thanks Marco for reminding me how I was just being the classical fool that looks at the finger pointing to the moon. In Marco’s words:

I see little value in mapping exercises (being it mapping XP or Scrum practices to CMMi or Open Development or whatnot). I see value in discussing commonalities and differences in values and principles and drive everything else from there.

Or, to put it differently, there is little point in arguing practices and processes, which should always be means to an end. He conceded that I’m actually in good company, though, as a large majority of Agile/XP die-hards have long since been sticking to practices for the sake of practices (“no pair, no party”, anyone?), ignoring the tenets of Shuhari, where practices are considered drills you should adopt and rehearse so that you can pick, choose and evolve on what works best for you. With this in mind, it might be a good time to see what are the commonalities in the “ends” and if there are incompatible differences.

Marco points out how the biggest problem might be the lack of a customer to satisfy in Open Source communities, something I could subscribe to but only if I’m allowed to note how there are usually many customers around a successful Open Source project, with every member of the community reporting to a different patron – herself included – with different needs and different priorities. The standard Open Development response to what could potentially be a serious stopgap in terms of different interests acting in the same project and pushing in different directions is clear, though: on one hand, do-ocracy and his French-speaking twin JFDI does the trick, and on the other keeping discussions and basing decisions solely on technical matters help tremendously as well. At the end of the day, this means that the customer is there – it just happens to coincide with the community as a whole.

Is that enough? Not sure, but I subscribe to what Ross Gardler writes on slide 26 of his thorough Agile and Open Development wrap-up. There just has to be a way to make Agile and Open Development sing in harmony: Agile has enormous potential to deliver, and Open Development can provide amazing peer review and long-term sustainability. Losing either would be just foolish: as long as there is room for middle-ground, openness and flexibility, I’m sure we can make it happen. More to come.

Software sustainability – the tour

A couple of weeks ago I was having an absolute blast in a small-yet-packed room at ApacheCon Europe, where I presented on software sustainability, a topic that’s very close to my heart. Slides are embedded below (and available here), even though chances are you won’t make a lot of sense of them (I hate bullet-point slideware with a passion). Don’t worry though, as I will have the very same talk modulo a few updates at the first edition of Better Software in Florence, May 6-7. See you there?