[Serdev] SER architectural decisions - was: So who/what is SER
for, anyway?
Jan Janak
jan at iptel.org
Thu Jan 25 17:22:40 UTC 2007
Dragos Vingarzan wrote:
> Olle E Johansson wrote:
>> Well, the same can be said for Asterisk. It's a problem with Open
>> Source, that
>> it keeps growing, hacks are laid on top of other hacks and there's a
>> shortage of resources for a re-start. In some cases, it happens through a
>> fork, in some cases within the project - like Apache or JabberD.
>
> Yes, this happens a lot, but when there is a clear and independent
> leader, maybe he could push big changes, cut branches, create new ones,
> etc. When there are many, some of them would certainly have other
> interests and would want to keep the current tree as it is. Why break
> something that works just fine for some, right? But my impression is
> that too many core developers are just happy with SER and its position
> now to accept something really new, like a direction change. Maybe some
> developers are too afraid that the new version would not be accepted and
> used by the community if at the beginning it won't be on the par with
> the old one... Am I wrong?
We have done big changes in Ottendorf, changes that are not backwards
compatible but were long overdue, so I am sure we are not afraid of
doing big changes. We repeatedly broke things that were working to
make them better, that's something that you could see from commit
logs. At the same time I am happy with the general SER architecture
and I do not think we should change it into something completely new.
I am personally not interested in doing radical architectural changes
and turning SER into an application server, because that's not what we
need, so yes, we might have different goals then you have and I see
nothing wrong with that.
Nothing prevents you from creating another branch and turning SER into
something new, that's probably the easiest way how you can you push
your own radical changes. If you are the only leader of your own
project then you do not have to make compromises with others.
Jan.
More information about the Serdev
mailing list