hi thomas.
Thomas N. schrieb:
Hi,
the recent discussions about the import interface revealed a conflict between
two goals of open source software development, that split the developers in two
types:
- enhance the codebase to make it maintainable, extendable and state-of-the-art
- add new domain specific functionality that users need
since i'm guilty of being involved in the discussion you mention, i'll
answer here, too.
there are already 4 new messages in that thread, so i'll keep it short ;)
(The purpose of this mail is to clearly state that I'm more interested in the
latter, and also make clear that both is extremely important, I don't want to
judge over which one is more important.)
About the second goal first: developers working on that tend to not care about
the internals too much. They are often users of the software and have a clear
idea of new features they would like to see. They just implement them, trying
to follow the coding guidelines and existing interfaces, but they are also
willing to introduce dirty hacks for the sake of their desired functionality. I
must admit that I'm of that type. When I look on the activities in the ArgoUML
project, then I get the impression that we're weak here. But the main intention
behind open source project is that users add needed features and share them
with others!
i don't agree much here.
for me it's a very big advantage in doing oss to *not* bring out
bells-n-whistle-features every week and push them into market, that's
what m$ and other companies have to do.
we don't have that pressure, we can spend more time in bughunting and
stability of the software we write.
of course we should also bring new features, but we shouldn't do it by
introducing lot of bugs. linus should be the hellhound behind our necks
here, but it's a question of his time, of course.
About the first goal: it is extremely important, because it provides the basis
on which new features could be integrated. Developers working on that have a
clear understanding of software engineering and carefully watch about used
patterns, interfaces, processes and such. They prevent the project from chaos
and the death of unmaintainable monster code. Their goal also is (or should be)
to provide a framework on which extensions by the other type of developers can
safely and easily be coded. I think ArgoUML concentrated on that for a long
time.
i don't think that we are building frameworks for uml-tools, but we
should have a stable, enhancable architecture for argouml.
if people want to push in code and don't have a clue about patterns,
interfaces, etc. than i honestly don't want their code :\
it's a very bad idea to let everyone hack argouml and hope that the
long-years members will clean up the mess.
There are common interest and goals of both developer groups for sure, like moving to UML2. But sometimes there arise conflicts which must
be handled: the "user" developers introduce dirty code that makes the life of the "framework" developers hard. On the
other hand, the "framework" developers always restructure the code base that sometimes can prevent the "user"
developers to code something usable within their limited time. I'm a "user" developer, as stated before, and had to postpone my
feature ideas for YEARS for several reasons, sometimes I even had to abandon plans. First there was the breaking of sequence diagrams, then
the move from NSUML to MDR, then multiple reworks of whatever event mechanism, now we will have sequence diagram 2 or 3 and
UML2/EUML/AMOF/DI/... and so on. Back then there was Thierry, then Jaap, and I thought "ok let them finish their work, then I'll
continue", but now I see this is a neverending story. (BTW, now we have good old Tom that follows that tradition, hey Tom, don't
misunderstand me, I appreciate your work VERY MUCH!)
i'm also not very happy with the step to euml, because i can't see a
"master plan" for going to uml2, this should imho maybe even a branch.
of course it would be cool, if you can switch from uml 1.4 to 2.x in
argouml, but on every deeper look to the specs this seems pita.
[...]
regards,
alexander
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
