Originally posted by bootstrap
My opinion is - let him do what ever he wants.
This sounds like an excellent summary of what I'd also consider a good
approach for dealing with this situation.
On the technical side: I agree that separating the GUI from the protocol
engine makes a lot of sense: it should be much easier to get a program
without direct user interaction stable, one can use better and automated
test procedures, data structures can be chosen for efficiency, not GUI
constraints, etc. In fact, I'd consider the close integration with the GUI
the most important technical flaw of the mules.
Whether this appears as a library or as some IPC interface, is mainly a
question of taste. Of course, it makes perfect sense to put the actual
engine into a separate process, in order to allow it to run without GUI,
to protect it from bugs in the GUI code, and also to have more freedom
in implementing event loops, synchronization, and such.
On the licensing side: changing licenses while in the middle of a project
is hard. In particular, you can't go from GPL to LGPL, unless all
copyright holders agree. Fortunately, you can go from LGPL to GPL
(see section 3 of the LGPL).
I wouldn't be particularly worried about picking the LGPL. Since the
main interface of the protocol engine would probably be something
message-based anyway, it would be messy (although possible) to
try to place major restrictions on the use of that interface. A library that
translates this interface to something more convenient would both be
simple to implement, and easy to replace with something under a
different license. (Well, unless you're going to patent it :-)
On the "team player" side: some people simply don't interact well with
other people. This doesn't mean that they can't be useful in a project,
quite to the contrary. You just have to make sure everybody accepts
the constraints this imposes. E.g. if you have more than one developer
who anxiously defends his territory, and these territories overlap,
you'll quickly end up spending more time with fights than with coding.
Of course, this might still be great fun to watch.
Also, adding more manpower to a project usually makes the project
slower, not faster, because communication overhead increases
exponentially with the number of people, and some tasks are difficult
to share among several people, particularly if they're not exactly
soul mates.
Unfortunately, all this not only about technical skills. Sometimes,
people cling to a position because of financial reasons, because they
covet the prestige that goes with it, because they fear that, if they
changed their mind and did anything else, people would think less of
them, etc.
Keeping people apart isn't as bad as it may sound, particularly if
they already work best if alone and undisturbed. Also, even if this
means to redo major parts of a project from scratch, this isn't
necessarily bad: once you understand what the parts are, and how
they should interact, the actual implementation usually feels easy
(it may still take a while to do the typing, though :-). Also, code
written by one or a small number of developers will have a more
consistent structure and bugs will be easier to eliminate (plus there
will be fewer misunderstanding or problems because of working
with structures one is less familiar with).
So I'd suggest to try to get a rough understanding of an interface
between GUI and protocol engine, then let people work on their
parts, and not worry about overlaps. Particularly in the Open Source
world, people work best on things they understand and that they care
about. If there are mayor missing elements, somebody will probably
eventually be sufficiently annoyed about them that they start to care,
so the problem solves itself. (We have to show at least some
optimism, right ? :-)
Well, this summarizes a bit of my experience with such things. My
own approach is to either stay out of the battles, or to assume a
key role. So I can sympathize somewhat with Un-Thesis' position.
However, I also try not to step too often on other peoples' toes.
- Werner
Author
Topic: The Un-Thesis Proposal to aMule Team (Read 38684 times)