How to criticise?

I wish that I had more time to respond to this! :)

Here are a few things - in no particular order - that I think that really help make the discussion/critique process more constructive.

Goal
----
Identify the most focused end goal that relates to problem at hand. Try to get consensus on the goal first.

Keep on topic
-------------
Try to keep the discussion focused on the goal. If other issues are come up, make a plan to address them later and then prune them from the thread.

Ignore Trolls

Adopt roles
-----------
Adopt different roles to help get better perspective on discussions. Play Devil's advocate for your favorite idea. Play vendor's collaborator for the ideas you despise most. ;)

Get outside perspective
-----------------------
Talk to a friend or colleague who knows neither side of the discussion.

Forking vs. Threading
---------------------
If you have a project where forking is felt to be needed, think about 'threading' instead. ;) Have enough separation to be able to make decisions indenpendently, but share resources like debugging, mailing lists, developers, etc.

Ego
---
Keep ego out of it. As soon as people start arguing over who is right, instead of what is right, the trouble starts. Don't defend ideas just to be right...

Be nice! :)

Somehow i think it's ok for a free software group to refuse someone or an idea. After all free developers don't need to take responsibility that everybody feels happy. While companies propose the "happy customer" to provide for their profits, as a free developer i like to collaborate with others for my and others benefit. If someone says "you are not making me happy" i ask for the reasons and try to distinguish what is his problem and my part in it. No guarantee that i solve the other person's problem.

btw: Taking part in successful free cooperation is way to much fun and motivating so that i take some drawbacks with a smile. Mostly.

Holger

Someone who's thinking of starting another open-source project may want to ask Linus Torvalds how he managed to keep the Linux kernel from forking into several different strains, even though there are thousands of people working on it. :)

i wish... that advogato had started back in 1997. i would have been posting articles at a time when things were going really well. people who have only been around for the last two to three years would realise quite how stark the contrast is.

i can attest to the necessity of sticking to some guidelines.

the following realistically applies to _really_ big projects such as apache, perl, python, linux kernel, worldforge.net - anything over 200,000 lines of code.

use an appropriate development environment for communication and decision making.

1) use an equal-rights arrangement.

the ASF charter, other than "we own all your code" [which is quite a good idea as it helps with the charter, but _is_ quite risky in other ways], is very good.

the ASF charter basically says, "anyone on the cvs commit list may veto, on _technical_ grounds only, any patch. everyone _including_ the project leader[s] has equal rights. anyone may leave and your code remains with *us* because by joining the project you handed over all your code _to_ us and _to_ the project."

so other than the ASF itself becoming a legitimate target for corporate america sue-the-pants-off-them court cases, which could terminate with extreme prejudice any ASF-owned project, it's a good idea. [btw, the ASF is _not_ a charity it is a corporation].

the ASF charter stops people from deciding "i don't like this person, therefore i'm not going to let any of their work get committed". it also stops the project leader from getting out of their depth. if the people they are supposed to be leading are more technically competent than _they_ are, then a new "leader" emerges simply because the so-called "leader" will not be able to give appropriate technical counterarguments for proceeding in the direction as implemented by the majority.

so it works very well.

2)

use one and only one person at the "top of the tree". noone but them has commit rights. they make all the decisions about what goes, what stays.

this is risky, but it stops fights. it _also_ depends on the underlying architecture of the project being suited to demonstrating to such "top of the tree" leaders where they are going wrong.

apache, perl, python, linux kernel, bsd kernel - all of these projects have "dynamic loading" capabilities where almost _any_ part may be replaced at runtime at the whim of the user / developer. this is an incredibly powerful and flexible mechanism that makes any decisions to reject a patch based on some arbitrary and technically incompetent basis utterly _irrelevant_.

and guess what, boys and girls? samba doesn't HAVE a dynamic loading capability. yet.

samba's underlying library-codebase is actually very similar to apache's - freakily so. both projects have their own implementations of initgroups() for example, where samba's implementation is actually superior to apache's.

so, samba is a good example where things _can_go wrong, and _have_ gone wrong. fortunately, they recognise this, deep down, and are looking for ways to fix it.

so, the reason why Linus is successful at the "top of the tree" is because the architecture helps him. Apache has an un-told number of mod_s available for use, out there: well over three hundred, i heard Ryan once say. Python and Perl are object-orientated programming languages: you can write your own modules as code, either in straight c via an interface, or even by any _other_ language, and there's even a program to help you do it, called "swig"!

the only other thing that i should mention is that keeping your temper and "being nice" is not necessarily the best thing to do.

having a _really_ good slagging match can often clear the air and achieve results far better and be much healthier for everyone involved.

once this [samba silliness] is all sorted out, i _really_ look forward to going down to some pub and getting roaring drunk with andrew and jeremy and the others [and i don't drink], to make up for three years of really painful decisions and words.

What I meant in my example of Linux is this: there are thousands of developers working on it, and disagreement is certain. Even what constitutes a "good" software architecture is open to debate. E.g. it's well known that Andrew Tanenbaum believes that an OS should have a microkernel architecture (unlike the monolithic architecture Linux uses), and doubtless hundreds of other people believe so too. And there's really nothing to prevent someone from forking off the Linux kernel project into a "microkernel-Linux" branch. But this hasn't happened. Why?

In other words, there's more to this issue than just having a "good" architecture. Linus must've done something to prevent forks, but this something isn't purely technical. (ESR's CatB paper only says one should "lead without coercion", but leadership is itself a big topic.)

On the side of the `ordinary' developer, whenever I create a patch to a project, I don't insist that my patch be accepted -- because I know that if I am a maintainer of another project, I too would like some control over what goes into my code base. What I do is to submit the patch (and hope it'll be accepted), and at the same time upload the patch somewhere and publicize it so that interested parties can try it out -- and stop there.

Forks may be beneficial to the communities' development processes in both the short term and the long term.

Consider a possible fork situation:

A troll (this is obviously correct nomenclature to your faction but less so to some others) exercises sufficient influence to create an impending fork.

Unless the original group holds a grudge indefinately, it should be possible for erring troll influenced contributors to return to the fold; after the troll team's fork fails to sustain enough developer interest or productivity to achieve meaningful result. Indeed, with a bit of caution, confused neophytes may even be able to contribute productively to both or all factions until a personal or technical preference (non final or binding I hasten to add) becomes clear. In the meantime the multiple smaller groups should have less productivity hampering internal conflict even though more agreement or common ground is not guaranteed, providing a higher probability of some useful work to getting done.

If the fork is successful then two smaller or delayed projects projects exist (assuming of course that the original non troll majority has also prosperred, reasons sometime exist for project leaders putting up with dreck from troublemakers or prima donnas unless threshholds are passed). Both new projects now face the possible necessity of descoping the project's original goals or delaying the implementation schedule ...... or do they? Two or three developers with a high level of compatibility may be much more productive than 6 to 10 developers enduring frequent and lengthy technical debate or personality clashes.

Granting that forking ad infinitum to atomic single developer projects does not seem desirable in the face of the often large scale of modern software projects ...... it is not clear to me that forking is a negative influence in the community; unless the experience discourages develepers and users to the extent that it actually shrinks the community. Perhaps open source evolves high quality code as much from the ability to instantly fork and thus focus efforts on more concise coherent sets of goals as it does from many developer resources. When was the last time you instantly quit your day job over a personality clash or technical issues? Where else do you have the luxury of abandoning unpleasant associates while staying in touch with the pleasant ones and keeping the current version of the common work to expand upon?

Perhaps our concern should not be forks or forking ..... but rather how to define project intangibles and list etiquettes adequately that polite forking results when appropriate rather than community shredding and/or shrinking conflicts sustained over long periods within the original project "team" or "community".

Perhaps we could consider polite forking to be a form of factoring. Our master project leaders could soon be bragging about the huge projects they had successfully refactored into successful subprojects.

The non trivial question of which license encourages or discourages polite forking is left as an exercise for the discerning reader to discuss with his/her mentors. 8)