project leadership and community

In Free Software development, we sometimes see a smart person alone creates a useful program, and as its popularity grows, more people become interested and get involved. The response of the original author to the growing popularity at this stage plays a critical role in whether the program continues to succeed or fail, or end up in multiple forks, due to different visions of the original author and the new people. What is the best strategy on the part of the original author to maintain the community and continuing successes while incorporating the new energy?

Free Software projects often started from one person. One smart hacker may create a program that's so useful that it soon has a large following. With Free Software being open to all, soon other people jump on board and begin to offer patches, or even help generate releases. Minor patches usually do not end up with political problems, but the original author may get into conflict with project contributors over diffferent technical visions or project ownerships/roles. What should the original project owner, as now a proejct leader, do to maintain a healthy project, with inclusion of the new positive energy, while still maintaining coherent vision or direction for the project? As generally, it is for the best interest of the community to have the orginal project to continue as one, to continue to grow and to evolve without forks.

What quality should the project leader have to succeed in this regard? Or, for someone with no prior experience, what would people suggest to such a person to learn to master the art of, well, project leadership? What are the secrets in successful examples, such as, Perl? (the Linux kernel often is cited as such an example, but I think the Linux kernel may not be representative of most projects, while Perl and Samba better represent the experiences of more Free Software projects started from a single person that are successful)

Especially, for someone with strong ego and personality, say, the hacker who "started it all" for a project, how can he or she change his/her ways, which may be painful, to be a successful project leader? How can others best convince him/her to take such an action?

(Note I am not in such a position; I am asking this as one observer to some Free Software projects)

"Especially, for someone with strong ego and personality, say, the hacker who "started it all" for a project, how can he or she change his/her ways, which may be painful, to be a successful project leader? How can others best convince him/her to take such an action?

(Note I am not in such a position; I am asking this as one observer to some Free Software projects)"

Often there are two distinct logical ways that a software project can evolve, and strong opinions on each side. Splitting into two camps can sometimes be a better idea than winding up with an architecture that isn't optimal for anything.

And there are some people who just embody that old cliche from Westerns: this town ain't big enough for the both of us (hello, Theo). It might be better to split and have two competing projects than constant wars.

And then there are the strategic forks. I was one of the people involved in the egcs conspiracy. With that one, we carefully designed things so that the fork could be mended (for example, we kept requiring assignments to the FSF for all code), because we wanted to wind up owning it all. And that's exactly how it played out.

yeupou, GNU is not what I referred to. The projects in my questions are single-program projects such as, say, a programming language implementation, like Perl. People like RMS are not what I refer to by "a single person who started it" although he could be one if you just consider the context of Emacs as a project. But Emacs is already too old for the questions of this article to apply; I think it is more interesting to explore ways for new projects to avoid the history of forks as happened in Emacs.

yeupou, GNU is not what I referred to. The projects in my questions are single-program projects such as, say, a programming language implementation, like Perl. People like RMS are not what I refer to by "a single person who started it" although he could be one if you just consider the context of Emacs as a project. But Emacs is already too old for the questions of this article to apply; I think it is more interesting to explore ways for new projects to avoid the history of forks as happened in Emacs.

1.)You created a neato paradigm that has established a community of users but have no desire to babysit new users .... give project leadership away. If you are in it for the coding resist the ego expanding hero worship and simply remain a coder.

2.)Acknowledge that other coders are now going to increasingly out perform you as you are now spending vast amounts of time learning leadership skills and actually leading....er....catering to the whims of the talented and energetic coders and users, mediating and then ... after appropriate decision matrixes have been formulated to load your intuition and other leadership processes ... deciding or pitching for the vote. Keep in mind volunteers always vote with their feet.

3.)Fork subsets or new requirements happily .... hand appropriate pieces to appropriate teams and keep your desired segment, sanity, and priority time allocations for yourself and your family (significant others). Keep in mind you can always shift, migrate, reattach yourself to the other project teams if they successfully keep part of your baby alive and thriving or need your maternal attention for an ailing child.

4.)Other: Improvise as appropriate. This is a test, the universe expects results and there will be consequences no matter what you decide or fail to decide. The essence of leadership is whatever it takes to get more than one person to work productively (probably happily, joyful cooperating workers can flat out produce when they wish to) together towards the common vision. Notice this requires a common vision thingy. Which leads to a fundamental requirement to identify individuals' goals, desires, and ways to helpfully superimpose venn diagrams to the mutual weighted satisfaction of critical team members and regulators to avoid the aggregate minimums and valleys that are always lurking around the hills and poles.

Hum, while I tried to be somehow subtile and vague, you exactly got my point. :)

Well. There's XEmacs and there's Emacs, there's GNU/Linux and it could have been GNU Linux, there's FSF and there's OSI. Frankly, I cannot help it, your description of ego issues leading to conflicts made me think of that - probably because of issues (that were not personal, despite what has been said by some persons) I had with the FSF USA, granted.
Is RMS a succesful leader in general or is he succesful leader just in the context he created and maintain at any cost (are recurrent conflicts he got just based on political grounds, as he claims? there should not be political issues with non-political people like Linus, there should not be political issues with GNU volunteers ; and yet, it happened numerous time)?
And, finally, what will be the future of the GNU project after RMS (because no one is immortal you know), so dependent on the FSF USA that is structurally more than overly dependent on him? Is a succesful leader someone you cannot live without or the exact opposite?

I understand you desire to speak only about "single program", but the question you raised applies also to this example. And maybe it could interesting to think about it, considering how GNU is important and how it's loss could affect us, considering how severe management issues can affect the free software development.

RMS is definitely one of the most important, if not the most, leaders of the free software world. It makes of him a quite interesting example, hard to avoid, when it comes to the subject you mention. Your question was what does it take to be a succesful leader?. It is probably best to ask first what is a succesful project?, isn't it?

(No, yeupou, that's a different question. If you want to answer
that then you could always start a new article.)

I think mirwin's reply is good. I suspect a lot of the
required skills
are the same as for a project leader on commercial software projects, or
even on non-software projects such as Arctic expeditions!
You have to trust your team to do the work,
constantly checking and questioning everything they do doesn't scale,
and doesn't inspire them.
You have to explain the goals and how particular designs or methods
help to achieve them, and discuss those goals with the team!
If you have completely different visions
for the project's future it's better to find out early.
Delegate tasks to competent deputies.
Praise people for
their contributions - they're more likely to contribute again and to listen
to your feedback if you show you're grateful for their help.

Some aspects of leadership on a Free Software project will obviously differ from
other projects (e.g. you can choose to incorporate code from another Free project)
but I think there's probably a lot in common, and would-be
project leaders might be able to learn something useful from a good book on
management and/or inspirational leadership (if such a thing exists :)

i began writing up an article on software freedoms that incorporates free software licenses, the right to unencumbered documentation, and the right to respect for all the principles that make free software successful. i hope to complete this article and publish it at an appropriate point.

here's some questions that demonstrate that free software is a bit more than just "a license" and "a project leader". the solution involves things like a charter (or other agreement to respect and cooperate and encourage).

what good is a free software license if the developers "raise the bar" so high that they will not accept patches?

what good is a free software license if the developers deliberately will not cooperate with or interoperate with other free software projects - massive, multi-man-decade projects - and instead choose to reimplement those services, providing "built-in" alternatives with non-interoperable administrative interfaces?

(yes this really is happening in one very large "free" software project, and yes, admins are genuinely concerned that they will have to "port" their entire infrastructure over to this "unproven" and non-interoperable replacement software with its new config file formats etc.)

what good is a free software license if the developers ignore existing standards (and ignore free software that already implements those standards)

you get the picture, i am sure.

if a project's scope is small, affecting a few thousand people, such issues are irrelevant.

if, however, a project's scope is somewhat larger - of the order of a few hundred thousand or a million installations - or the potential install base (if a project gets it right) is an order of magnitude bigger than _that_, then the burden of responsibility is far higher.

not many people can cope with that burden of responsibility: instead they believe that because of the responsibility, their decisions must be endowed with extra weight, and must somehow be right because of that.

whereas in fact, the additional responsibility means that you must take EXTRA care to design your software such that it will incorporate as many people and as many new ideas as you can possibly imagine.

to WIDEN the scope of the project not to narrow it and to DECREASE your own burden of responsibility rather than increase it, by offloading and outsourcing to other projects as much as you can.

of course, if those projects then screw it up, you are in an ideal and well-informed position to either help them, advise them, fork their project and beat them about the head with your fork until they get with the picture.

... but to say, for example, "oh no, nobody can get it right except us, nothing that already exists is suitable for our needs, therefore we must entirely reimplement an interoperable kerberos (300k+ lines), entirely reimplement an interoperable ldap (250k+ lines?), entirely reimplement a an interoperable dce/rpc runtime environment (280k+ lines)" is just complete madness.

redi"(No, yeupou, that's a different question. If you want to answer that then you could always start a new article.). Indeed it is a different question. But how can you answer the first question without carefully studying its terms? How can you seriously say what would be a succesful leader if what means success remains undefined? That's definitely a serious methodology flaw.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.