14 Jun
2005
14 Jun
'05
10:30 p.m.
Bogdan-Andrei Iancu wrote:
having multiple options instead of only one proved in
many case to be
a progress engine. I would rather say that both projects will benefit
from this. And most important, the user (don't forget them) will: they
will have a larger diversity to choose from.
indeed, time (and to be more specific, allocated time for the public
SER) was an important factor for deciding to start OpenSER. Also
another factor was how to deal with new contributions and how to
*help* them to get into the main stream. Placing them in a separate
directory I think will not help too much - see the history of the snmp
module.
and about splitting the time between the two projects - I don't thing
will be a problem for us since we are the people who complain the
thing are not fast enough ;)
bogdan
Diversity is not necessarily a good thing in every situation, for
example diversity in a limited resource environment can lead to less
effective use of those resources and, in the end, may lead to the
opposite of what you describe (a progress engine).
Also IMO diversity seems to be a argument against proprietary software
models, such as "Application X has this features A,B,C and doesn't see
it as necessary to implement features D and E for whatever reason
(generally non-technical) so i'll use Application Y because it has
features D and E (which i really need) however it does not have feature
B which i can do without"
An argument against proprietary models and (generally) not OSS because
(by definition) the latter is open to improvement and modification by
anyone who wishes to take the time and because of this a community is
created around that project. If there is a problem then, as a
community, we should make every effort to deal with it as such.
Now i don't particularily want to approach the problems associated with
self-defensive, impressionistic territorial behaviour that is quite
common in most OSS projects but it is (IMO) a serious one which is taken
into consideration by (i believe) many who post requests. If you have a
hard getting your point across i can see how it may seem impossible to
enact any great change without a very large amount of effort in which
case a simple branch is the easiest solution
I think if you really are serious about branching SER you should first
consult with the developers and users of SER to find out what they think
and if there exists a way resolve (or objectively document, for
reference in the least..) the issues you are having. I think that this
would be a reasonable approach, your sudden declaration of a branch is a
total surprise to (i'm sure) everyone on these lists and i think it may
not be the best approach.
tavis