This morning, I stumbled across Linus Torvalds’ talk on git, the distributed version control system that he created for the linux kernel and I watched it, mostly out of curiosity, because I never heard Linus speak and because I was somewhat curious to hear him speak about his notoriously heretic views on version control.

His bashing of existing, centralized version control systems is so in your face it’s actually funny and not at all insulting, but I found myself curiously defensive while hearing him bashing the CVS/SVN model of a centralized repository.

I started using CVS in 1997 when I first committed a change to the Apache JServ project. I sent over the java class that I modified attached to an email message. The JServ developers replied “send a patch instead” and I replied “what’s that?”. I was 22 and I was (back then) a windows user. But in order to see my patched back in JServ (and avoid having to maintain my own personal branch over time), I had to find, install and learn things like diff, patch and, ultimately, cvs.

Let me tell you: I hated it. With a passion. I hated any command line thing, really, so I found myself WinCVS and used that… but the whole process felt awkward and counterintuitive.

Fast forward 10 years to the present, thousands of commits later on tens of different projects (0pen source and not) and a transition from CVS to its repainted and remodeled cousin Subversion, and I find myself defensive hearing somebody expressing the exact same feelings that I had 10 years ago.

To be honest, it’s hard to separate my dislike for CVS from the feeling of it being complicated and unnecessary for somebody that always worked alone on his software or with a couple of close friends.

But as I watched Linus’ talk, my defensiveness slowly morphed into fear, the fear of defending the use of a particular technology not for its merits, but just because I’m used to it and I’m comfortable in its own quirks and limitations. The brain equivalent of muscle memory, so to speak.

I’ve always thought of myself as better and more open minded than that, but what if I’m just as bad? or what if I’m growing more lazy and rigid as I get older?

That fear, if anything, made me try git. I downloaded the source code, build it and ran it. I didn’t even read the manual, I just launched it and I was already impressed: one of the supported commands is “bisect” and the help says “Find the change that introduced a bug by binary search”. I have no idea (yet) on how it works, but I had wanted that feature, somewhere, somehow, for years and I even thought of implementing it in Gump3 (but never got around to do it). That’s enough to get me try it for real in the near future.

Linus’ main idea in favor of distributed version control is that, as humans, we are naturally social beings and we deal with trust and respect in a social way: one way is to create a gate and select who comes in and out (the centralized, walled garden, grant-commit-access way of doing things), another is to let everybody have their own personal branch, where nobody is fixed in the center and anybody can pull from anybody else in the network (the center becomes really a centroid, the center of gravity of the network and can move more easily over time).

I had dismissed such ideas as heretic in the past because I thought that centralization was the only mean that could maintain brand control and provide a consistent legal framework upon which to operate.

But I know think I was just being scared of seeing the pillars of the social structure of the projects I was involved in crumble under the pressure of a displacing innovation.

I listened to Linus today indicate how branching is vital, centralization is evil and innovation should not be walled nor restricted and trust is a social graph percolation problem… these are all things I truly believed in myself and that I actively evangelized in other part of my life and career…. but I never realized that I was using and I had choose to use for my own personal projects and my day job something that, in truth, is designed around an old, centralized, vertical and monolithic vision.

Linus claims that he won’t directly trust more than 15 developers. I’ve been there myself, as technical leader of a big open source project and I completely agree with him: the development core cannot possibly be larger than that because the coordination costs alone will make it impractical to do any work at all. If let free to organize themselves, such flat development networks tend, naturally, to organize hierarchically, if only to isolate the broadcasting range and optimize the execution of tasks. So, if Linus trusts 15 people and each one of them trusts 15 people, you don’t need a lot of layers to cover a huge amount of developers working together on a particular project.

Linus also claims that without walled gardens and commit access, there is much less need for politics around granting commit access. Well, truth is, he’s the undiscussed dictator and his branch is, in fact, the central branch and he’s the one deciding what gets in and what doesn’t. That, I believe, is what reduces politics not any version control architecture.

At the same time, it is true that even oligarchic projects tend to get less and less prone to give away “commit access like candy” (as some apache people tend to criticize my suggested practices of having a very low barrier of entry for committership) the older and bigger the project (and the social network) becomes.

Fact is, Linux is a project that has never experienced a leadership transition and according to my own rule of thumb for long-term community health, Linux scores pretty low because of that.

At the same time, if Linus was to get hit by a bus tomorrow, somebody else (obviously one of those 15 that he trusts directly) would step in and become the new social centroid (note: centroid != center).

Apache is proud of not having an overall ‘leader’, but, let’s face it: there might not be anybody that is “Mr. Apache” but every project always has a community centroid… it might not be the same person at all times like for the Linux kernel, but it actually helps to have one. I have been one in many different projects and I felt that the community liked the concept of a benevolent and well respected ruler that would step and help in those rare cases where the community couldn’t self-organize consensus around an issue. I’ve always felt the need to find my successor before stepping down and moving on to something else to avoid letting the community destabilize itself during the search for that person (which I think, in most projects, it’s the PMC chair)

I don’t see Apache changing version control system anytime soon (if only, ehm, because several of its board members are also subversion developers), but that’s not really my immediate concern: what I want to understand is whether Linus’ implicit claims that centralized and branch-phobic version control systems are suboptimal to the gathering of user innovation is true or not.
Because, truth is, I’ve never actually expressed that myself, but watching his talk made me crystallize that thought in my head: how many potential contributors did we miss because we didn’t give them commit access soon enough or because they didn’t feel comfortable revealing their patches back to us? How much less work could I have done if we had used a different version control system? How much more innovative could our projects be if we didn’t use a centralized design and a walled garden?

In his infamous “Linux is obsolete” debate what Tanembaum didn’t understand was that Linus’ secret sauce was not going to be technological (which he was right to criticize as Linux wasn’t exactly shining architecturally) but social (which didn’t even enter his radar).

I truly wonder if in sticking with the consolidate model for version control, we’re not making the same mistake.

Let’s say you’re given a task that you know how to accomplish: fill two rectangles drawn on a piece of paper with a pen.

Of the two rectangles, the first (A) is larger than the second (B).

Which one do you start coloring first? Do you fill up an entire rectangle before moving to the other one or not?

Now, let’s introduce another factor: who gives you the task also indicates which rectangle is more important to be colored first.

Do you follow the direction or still proceed as you would if no priority was assigned? And does the area ratio of the two rectangles influence your decision?

Here is how I operate: if no priority is assigned, I start coloring B (the smaller one), finish that, then move onto A (the bigger one).

If priority is assigned to A, I still do B first, unless the areas of A and B are so similar that I can’t distinguish them. If priority is assigned to B and B is substantially smaller than A, then I do B first, if not I start B, then move to A, finish A and then come back to B.

Let me analyze that behavior: I tend to do smaller subtasks first, as to be comforted of being making progress. I perceive a strong cognitive pleasure in finishing tasks and a smaller task is going to yield that pleasure sooner and energize me for the bigger task and reduces the risk of avoid completing the task because boredom or external stimulation drives me away from the task.

But when the subtask ordering is imposed, my behavior changes: in a sort of irrational reaction to authority (mind you, even if I’m the one suggesting the ordering to myself at task design time!), my own subtask scheduling is influenced by the external suggestions. To me, the fact of raising the coloring priority on a particular rectangle acts similarly to having increased its area.Which is why, if B is scheduled first and substantially smaller than A, then I would still do B (because even with the cognitively augmented area, B is still smaller than A). But if, after the scheduling, B is perceived to be bigger than A, I would do A first.

I have also realized that the amount of pressure given to a particular task (up to you vs. suggestion vs. imposition) acts, in fact, as a proportional area amplifier: a subtask looks much more difficult to me when its scheduling is imposed and the area amplification is proportional to the intensity/lack-of-flexibility of the scheduling.

So, why is it that I perceive a subtask to be more difficult (or take more time/energy/effort) when its order of execution in relation to other subtasks is fixed? and note, not fixed by somebody that I don’t trust or whose authority I don’t recognize… this happens even if I’m the one creating the relations in the first place!

That is a mystery to me: I still have no idea why that is but after studying myself for years, it’s obvious that it’s exactly what’s happening.

Now, what I came to realize is also how that ‘imposition-based difficulty amplification’ leads, almost automatically, to be perceived as a tendency to procrastinate.

Basically, it’s a vicious cycle in which some simple task gets perceived much more difficult than what it really is because you have to do it, which means that it will be pushed down the schedule and other tasks will be done first, even if they were not so urgent and even if they are, as tasks, more complex.

Let’s ground the discussion with a few examples: you have to clean two rooms, one is smaller and cleaner but it’s very important that it gets done (because it’s where the guests will sleep and you have two hours before they arrive), the other requires much more work, it’s bigger and a total mess. I start with the bigger and messy one.. and in the process I cleaned the bathroom and the kitchen (that just required little to do) before attacking the guest room. I finished in time, but rushing and totally frustrated by my own schedule… achieving more than I even had to do.

Another example: you wake up in the morning and the night before you have given yourself a few programming tasks to start and finish for the day, sized so that you’re likely to finish them and feel good about committing and making progress. The first thing you do is reading email and blogs, reply to all of the emails that you need to reply to (if any), then clean your desktop and then start attacking the last one of the self-scheduled tasks.

This behavior is both incredibly frustrating (not only for my managers and my colleagues but for myself as well!) but it’s also surprisingly powerful: if one of the byproducts of such behavior is perceived as procrastination (and this is the bad one), another byproduct is an incredible attention to details and the ability to execute a ton of relatively complicated tasks at the same time effectively… basically because these are perceived as smaller, un-tasked or low-priority rectangles that can be colored faster and easier (even if it’s just a distortion of their not-being prioritized).

This priority-driven distortion is weird not only because it’s hard to isolate or understand where it comes from, but also because it’s hard to explain to others as it feels, from the outside, just a way to drag your feed to avoid doing what you don’t want to do. But this is very rarely the case for me as I’m lucky enough to be able to pick my own tasks at work.

The questions in my head, now that I have finally identified the source of my own scheduling behavior, are the following:

1. how common is for people to perceive a prioritized task as more effort-requiring than the same task un-prioritized?
2. since such a cognitive model yields to a perceived tendency to procrastinate, is this condition sufficient to explain it? and is it necessary?
3. is there anything that can be done (managing-wise and self-managing-wise) to help people that exhibit such behavior to be more productive and less frustrated about their own behavior? or are they doomed to execute efficiently and effectively everything but what they were tasked to do?
4. last but not least, can such behavior be changed?

Chris Oliver (blog) is the guy who patched Mozilla Rhino to implement continuations and implemented the Javascript-based flowscript engine of Apache Cocoon.

When Sun acquired the company he was working for (SeeBeyond) he moved on and started to work on a side project to write another scripting language for building UI applications for Java. He then called it F3 (form follows function) and I was honored to receive some of the first examples of it (when it was still called GBTDS for ‘GUI builder that doesn’t suck’) and to talk to him and my good friend Ricardo Rocha (of Cocoon XSP fame) in person (both live in LA too) to discuss some of his early design choices.

It was a time when DHTML was more and more appealing to me and I was moving away from swing and traditional GUI building approaches so using F3 was not (and still isn’t) appealing to me but not because of itself but because of what it requires to run (a very heavyweight JVM). That said, F3 is a very pleasant hybrid scripting language and has been heavily influenced by DHTML and SVG but also managed to introduce very interesting ideas (such as variable bindings).

Recently, F3 graduated and has been renamed JavaFX.

It’s really too bad that silly marketing names can make something elegant and thought out feel like an half-baked late-moment hack. And it’s also too bad that it seems that everybody and their moms are now pushing for their own platforms+scripting combinations (Flash/Flex, .NET/Silverlight, Java/JavaFX), which makes them look like “me too”-ish and makes people miss the real innovations that are actually happening in there.

But as much as I appreciate that the RIA idea is pushing for innovation in the software development environments and stacks, I also can’t avoid resonating with those who point out that these are yet another golden licensing cage and that the web is much more than that.

In any case, kudos to Chris for another outstanding achievement.