On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla daniel@voice-system.ro wrote:
[...]
Now, we are not saying that fork is good in general, otherwise it will be a fork each day :-), but when there is no willing to cooperate, hold-back policies and abuses for self-promoting I see no other way.
Let's try not to degenerate in another flame war and please try not to exagerate it: no willing to cooperate, hold-back policies and all the other stuff...
We will gladly participate in a *really* open source project. A very good example is the Linux kernel -- it is clear that many of the main developers and contributors are employed by major Linux vendors, which have enterprise/closed releases, but you don't see on the main page of kernel.org advertising for none of them. In the sources is no explicit advertising message, and so on ...
So the proposal is:
- move the project's main site on an independent host (I bet there are
people willing to sponsor the hosting)
- remove all references that are intended for private publicity
This will take a while as some of the other core devepers are either traveling or will be away for the next days (e.g.: me).
- introduce a better management of the project, allowing people to be
able to take over when someone is very busy or unwilling to cooperate
That sounds very scary... The general ser approach so far was every one is maintaining its own code and other people should not go over it without his approval (except for fixing bugs). The ideea here is that the code maintainer might have his own plans for its own module and he wouldn't want it changed "under him". If I'm away for two months I wouldn't like to not recognize what I've been working on when I'm back (this of course doesn't include bugfixes). There is some other point: a code maintainer might not accept a change. While the change submitor, might think it's the best thing in the world, not everyone might share his opinion.
- make the project really open for contributions and contributors.
Outstanding developers can be good reviewers for new contributors when the others are busy
Yes, I agree, but this doesn't mean that each and every contributions will be applied. In fact I do think this problem is exagerated a lot, given ser's history (you can look even at your linux kernel example, lots of patches are unanswered, and very few make it to the kernel).
- don't hide the new features from the community, we are on open source,
what is the reason to have that ... so each new featured should be described shortly to the community, otherwise keep it in a private repository
I don't agree with this (and with calling it "hiding"). This is a documentation problem. I don't think "document everything or don't add new features" is a good ideea. We do accept documentation patches, is just not realistical to ask all developers to document each new minor feature.
- the next steps in develpment should be discussed between the
developers to avoid overlapping and waste of time and to select the best way to do it
This depends on what you understand by next steps. I do see the potential for interminable discussion.
- members should have a fair attitude to the others and try to discuss
each issue is a nice manner (without trying to impose from beginning own opinion and ideas)
This is shortly how we see it. If you agree (improvements are welcome), then we can move forward together, otherwise we will maintain further our code from SER as well as openser.
Andrei