Re: Re: about your concept

Before I get into my reply, I would like to apologize for the length of this 
post (I know i certainly wouldn't read it carefully, or at all, if I were not 
already involved in the discussion, and don't expect many of you to do so) 
and also for fanning the flamewar.  I realize that this is generally off 
topic, but I have tried to avoid personal attacks as much as possible, and I 
believe I have a good reason to post it.

Y seems to be a promising project: I would love to see it succeed, and I would 
also love to contribute to it.  However, it seems to me that the way things 
are currently being done is clearly not working.  This is not to say that I 
think Mark is doing a bad job, it simply means that I believe there is a 
better way to do things.  While I clearly think that my way is a good way, it 
is obviously not necessarily the best way, and my main goal is to promote 
discussion on this topic, instead of having anybody who would like to see 
things improve labeled trolls and flamebaters.

On Thursday 22 July 2004 02:53, Andrew Suffield wrote:
> > And then *you* used the fact that you knew the head developer to merge in
> > a complete reworking of the network protocol without a sentence of
> > discussion on the mailing list until *after* you had merged the code in.
>
> I very much doubt that it was significantly affected by the fact that
> I've known Mark for a while, and rather more by the fact that I
> provided an arch archive and something Mark was interested in.
With absolutely no review outside of the two of you.  Certainly, it is 
possible for Mark to be the sole gatekeeper of all Y development, but that 
doesn't mean that is best for the project.  And certainly, while he is sole 
maintainer of the project, developers may make large, fundamental changes to 
the code base, submit them to him, and have them accepted.  This is not my 
point.

My point is that doing things this way does not attract developers, and will 
even detract current or potential developers.  At the very least, it is nice 
to announce that you are making those changes to the developer mailing list, 
so that other developers won't spend time doing what you are doing, or 
writing code that would be affected by your changes.  I would also like to 
note that this isn't just some rule I made up, but seems to be a common 
suggestion/guideline/rule for most open source projects that have or are 
looking to attract developers outside the core developer base.

> I don't see why you think the mailing list had anything to do with
> it. It is a discussion forum, nothing more. I can talk to people
> without using it quite easily. Not that there was much to discuss; we
> both knew more or less what needed to be done.
The mailing list has everything to do with it exactly because it is a place 
for discussion.  The problem is you are assuming that what you and Mark both 
"knew more or less" was correct.  Unfortunately, this isn't true (or even if 
it has been in the past, it won't be for the life of the project).

As far as off mailing list discussion, it has been my experience that this 
leads to a lot of problems and headaches, from a development perspective, and 
can lead to a rift in project goals.  As an example, I worked on a large open 
source project which had high concentrations of developers in the US and 
Germany, all of whom preferred holding discussions on IRC.  Of course, this 
meant that if a German developer had an idea, only the other German 
developers would be around to discuss it, and vice-versa for the US 
developers.  There where a lot of instances where one group of developers 
would bring up an issue, discuss it, come to a resolution, and implement 
their ideas, only to have the other group wake up the next day and say "Well, 
what about this better way of doing things?" or "Well, that has a problem 
when you do this." or "You just broke everything I did last night."  This 
gets even worse when you move the discussions to IM, private emails or 
in-person discussions.

Note that just because a person does not belong to the core group of 
developers does not mean that they don't have anything to contribute, don't 
have good ideas, or won't have their code severely impacted by changes to the 
core system.

> > At which point
> > you called anybody who thought there was a better or different way
> > "stupid" and "insane" and refused to listen to anybody else's opinion.
>
> Fiction.
Not true at all, here are some choice quotes.  I have taken them from a thread 
titled "Proposal for a minor change in the Y-protocol", specifically 
discussing whether commands between the client and server should be passed as 
strings or as integers, one of the major changes you made to the code without 
any formal announcement or design discussion on the list.

"And this is insane. The protocol would change depending on hardware 
architecture", "What are you smoking? Alignment is as hardware-dependent as 
endianness.", " You have to be really stupid to write socket code with 
alignment issues."

You might have had some good points, but the fact is, you were rude and 
responded to criticism in a way that stifled discussion and discouraged 
people from participating.  After all, who would want to point out a flaw in 
your argument when they know they are going to be called "stupid" and 
"insane."  This does not just affect the people you are replying to directly, 
but anybody who is reading the discussion and considering contributing.

Also, and I am only writing this because I am assuming you are going to attack 
the validity of their argument, and claim that your rudeness was justified 
and that no important talent will be missed, as you have done in the past.  
First, it is not up to you to decide who is too stupid to contribute code, 
especially when you have not seen their code.  And second, I think that any 
on-topic comments in a discussion are perfectly reasonable, even if their 
premise is incorrect, as it lets people see things from a different 
perspective, and can still point out flaws in whatever was thought to be 
"correct" at the time.

In the above case, the suggestion which you claimed would flat out not work 
clearly would work, as it has worked in X for around 20 years or so, even 
between hosts of different endianness.  (I am not trying to resurrect that 
argument, merely pointing out that what, to you, seems completely implausible 
is not, and that you are not the be all and end all of developers, completely 
incapable of making a mistake, a bad design, or an incorrect judgement call.)

> > Now i *dont* contribute code, and its mostly because i assumed that this
> > list was for people to discuss changes to the project, and that there
> > would be some sort of review process for getting code put into the main
> > tree
>
> All of those things are accurate, but it seems like you have little
> experience with free software development. The review process is Mark
> (and occasionally me) looking at the code, and not every discussion
> about the project happens on this list. Not least because of all the
> people who chime in with ill-educated opinions.
First, I don't see how my experience with other projects relates to my 
understanding of how this project is structured.  Second, you have missed my 
point completely, which is not entirely your fault, as I did not express 
myself clearly above.  What I meant by "some sort of review process" was 
actually: "some sort of open review process".  In my opinion, it is 
necessary, especially for a new project still trying to attract developers, 
that they make their goals and guidelines clear and open, and not rely on a 
single developer to review and comment on all code submitted, plus one person 
who "occasionally" reviews code, and who's influence over the acceptance 
process is completely unknown.

Regardless, I am not commenting on how the project is run, but how it should 
be run.  Restating the current form of project management is simply a waste 
of our time, as I understand and have stated what is currently happening (as 
far as I can tell from this discussion, we do not disagree on what is 
currently happening, but the appropriateness of what is currently happening).

> > You have probably lost many smart and talented contributers to
> > the project because you a) ignored them completely, or b) called them
> > idiots as soon as you see what *might* be a better way to do something,
> > or just didnt feel like looking at their code.
>
> I rather doubt that. We've lost a fair amount of dead weight though.
Certainly we have lost a lot of dead weight, that much is obvious from the 
lack of "Y crashes on startup" and "Y wont compile" posts.  However, there 
were also a lot of people discussing and doing development who seem to have 
dissapeared from the discussion and development.

> > In order for such a large project to succeed, there needs to be a large
> > and receptive group of core developers who can lead intelligent
> > discussions and make fair decisions about what to put into the code, or
> > provide good explanations as to why something *doesnt* end up in.
>
> No. I don't know where you got that idea. Quite the opposite really -
> for a large project to succeed, you need a (small) group of
> gatekeepers whose primary task is to say "no". That's the hallmark of
> every successful large free software project (Larry Wall gives a
> rather good talk on the subject).
Perhaps saying that there needs to be a "large" group was an overstatement.  
Certainly there needs to be more than one or two people controlling access to 
the repository.  In another thread where somebody wondered how Linus managed 
the Linux kernel development, you said "they use bitkeeper, we use arch".  
That only matters if more than one person has write access to the repository.  
If only one person can write to it, it doesn't matter that it exists, as far 
as code submission goes, because there is still only one person who can use 
it.

Generally, when a large project (see below) succeeds with only one or two core 
developers, as Linux did for so long, it is because that core was able to 
commit a lot of time to the project, was receptive to suggestions about where 
the project should go, design, etc, and was willing to promote discussion and 
admit they were wrong.  Even in the case of the Linux kernel while Linus was 
the sole maintainer, there was a relatively large (for the size of the 
codebase, etc) group of developers who actively participated in discussions 
and the code review process, and whom Linus was wiling to concede to if they 
were able to convince him of his errors or misjudgements.

This is not to say that the size of the core development team is the only 
problem here.  The openness (or lack thereof) is another issue I believe 
needs to be addressed.  As we saw with the XFree86 project, even though there 
was a reasonably sized (in my opinion) core group of developers, the fact 
that they were unwilling to listen to outside opinions or participate in 
discussions led to the forking of the project.

> This isn't a large project anyway.
Perhaps at this moment there are not many developers and there is a small code 
base, but this is an incredibly ambitious project, and at some point, if the 
project is to succeed and be developed at a reasonable pace, it will have a 
large number of developers and a large codebase.  The project management 
structure needs to be in place before that happens, and it needs to be 
designed to permit and accommodate the growth of the project, not to stifle 
it.

Thomas Stephens
[email protected]