On 06/14/05 23:30, reticent wrote:
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
OSS proved that some time diversity is a very good solution. Look at the number of the linux distributions. All contribute to kernel development and other software. They have same roots and backbone, but there are differences that make people to choose only one. I chose Debian because it is very open for contributions and develops faster. This happened after RedHat chose to close its public releases. I could have gone to fedora, but I found debian more appropriate for what I need.
Daniel
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
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel