Open Source: Either lead, follow, or get out of the way
On Debian, Linux, democracy, dictatorship and Software Architecture.
Software Architecture is about leadership
From my experience (and from my colleagues' too) software architecture is about leadership, about taking hard decisions that not all people share.
As D'Souza defines architecture:
Architecture can be regarded as a set of principles and decisions, rules or patterns about any system that keeps its designers from exercising needless creativity.
There's another interesting definition by Bill Venners in this article entitled Software Architecture is Leadership. Quoting:
A software architecture should not only explain how things are done in a software project, it should guide the team in that direction.
Of course, software architecture is something difficult to define. Bredemeyer Consulting has a page with lots of definitions of software architecture.
But all those definitions basically come to say that software architecture is a set of rules, a set of decisions taken to fulfill a set of requirements, and that those decisions influence the evolution of the software, and that constrain all further refinements.
When democracy fails: Debian
Ok. So one of the responsibilities of software architects is taking decisions that will influence the rest of the software lifecycle.
Taking these sort of decisions is, of course, vital to the success of the whole software project.
And if those decisions are not taken by leaders then the project is in trouble. If there're not leaders and followers then the rest of the people is getting in the way, and the project fails.
This is what may be happening to Debian.
Debian (the well known Linux distro), was founded fourteen years ago by Deborah and Ian Murdock (who, by the way, is joining Sun now). I am a dictator, but it's the right kind of dictatorship. I can't really do anything that screws people over. The benevolence is built in. I can't be nasty. If my baser instincts took hold, they wouldn't trust me, and they wouldn't work with me anymore. I'm not so much a leader, I'm m
I have been reading a recent interview to Ian Murdock's at Linux Format (March the 19th) where he talks about the current situation at Debian. Quoting (without permission, emphasis is mine):
The problem with too much process is you get into design by committee - you get into a situation where without strong leadership no one feels empowered to make decisions. Sometimes you have to make decisions that are unpopular; that's what leaders do. What ends up happening in this committee mentality is that no leader feels empowered to make decisions unless everyone agrees with him. And since no one as the size of the organization grows ever agrees on anything, no decisions ever get made.
That's the quandary that Debian finds itself in today: how can it get itself out of the situation it finds itself in?
LXF: If Debian was a do-over, is there some way that that could have been fixed?
IM: Frankly, I can see this on Slashdot already, so I might as well keep going! I think the fundamental mistake was this adoption of a democratic process, which happened after my time and I was opposed to.
And from this I can learn the following interesting lessons:
- Decisions have to be taken.
- Sometimes you have to make decisions that are unpopular.
- A democratic process is not always the best way to take decisions.
And, you know, it's Ian Murdock saying that. And I think he knows what he's talking about.
When dictatorship wins: Linux
The Linux Kernel is probably the open source project out there (that I'm aware of) with a stronger leadership.
Linus Torvald (a 2006's Time's European Hero) is a hard-to-beat leader. Quoting from this article at itworld.com:
So I'm likely to never "pass the baton" in the way people expect -- I'm not the CEO who gives up leadership. I'm more the technical lead who concentrates on one thing, and it has just happened to be the most visible thing. The way the leadership has evolved, and will continue to evolve, is that others handle other issues -- to the point where I'm already just one of many. I'm just the most visible one, and the one whose decisions most people tend to respect.
Linus' leadership is so strong that he defines himself as a dictator. A benevolent dictator. Quoting:
I am a dictator, but it's the right kind of dictatorship. I can't really do anything that screws people over. The benevolence is built in. I can't be nasty. If my baser instincts took hold, they wouldn't trust me, and they wouldn't work with me anymore. I'm not so much a leader, I'm more of a shepherd.
Being an Open Source Software Architect
If Software Architecture is about taking decisions then software architects are the leaders that make those come true.
And, as we've seen in those experiences in Open Source projects, good architects are not only people with good technical skills, but people with good soft skills.
The article entitled "Characteristics of a software architect" at IBM Developer works explains it quite well, I think. Apart from being a tecnical leader, a software architect must also be a good communicator, and a negotiatior.
These soft skills are so important that there's trainging of these. This example entitled "How to Lead, How to Follow and How to Get Out of the Way!, by Bredemeyer Consulting explains it quite well.
The fact is that I imagine that being a software architect in a big open source project must be really difficult.
You have taken some decisions and some people may not agree with them.
You may have created a generic filesystem system, for instance, that supports lots of different protocols, and then someone comes in and wants to change all that.
Of you may have defined an excellent classloading mechanism, that isolates parts of your code, and then someone comes in and wants to change all that.
And, as a software architect, you must be strong in your decisions, but at the same time you must be flexible to change them (if appropriate) and at the same time you must also be benevolent enough so as not to make people unhappy.
Possibly by explaining why those decisions were taken, what the benefits for the Community at large are, this is, by exploiting your communication skills.
Eric Raymond puts it nicely in his "The Cathedral and the Bazaar":
Both the fetchmail and Linux kernel projects show that by properly rewarding the egos of many other hackers, a strong developer/coordinator can use the Internet to capture the benefits of having lots of co-developers without having a project collapse into a chaotic mess. So to Brooks's Law I counter-propose the following:
19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
So here I come and ask: are you involved in an open source project? If so, how are your architects behaving? Are they "benevolent dictators" as Linus is, or are they just getting in your way (and not taking appropriate decisions?) And, more importantly, are you getting in the architect way? (by suggesting dramatic changes to a strong architecture?)
Or, if you're one of the architects at an open source software project, how are you doing your communications job? Why are you reading this instead of taking decisions? :-D
Now, seriously: I would appreciate any other links to this topic, because it's something that has attracted my interest lately.
Thanks in advance,
Antonio
blog comments powered by Disqus