Ulf,
> Frederik, by simply ignoring the obvious demands of many of the
> interested developers, IMHO you're simply doing a bad job in maintaining
> JOSM :-(
> If there is great demand from the community (and there obviously is),
> you as a project develop lead shouldn't simply say "I don't like it ..."
> - so we don't do it.
The problem is that I feel responsible for JOSM in a way. All we've ever
seen is people coming from the outside, people who have not (yet)
contributed to JOSM a lot, and the first thing they say is "yuck, this
has to be refactored".
How am I to know whether these people will really stay with JOSM after
they have been allowed to refactor it to their heart's content? It is my
true conviction that many things will actually be *harder* to do once
they've done their work, not *easier* (especially for programmers who
are not Java experts). Will I, as the JOSM maintainer, be able to count
on these people to actually do the important work (i.e. adding features,
fixing bugs and so on) AFTER they have turned JOSM inside out - or will
they just continue to find reasons why they cannot contribute to JOSM as
it is, or (even worse) move on to refactor something else, thinking
they've improved JOSM when in fact they have made life more difficult
for the existing developers, all with the promise that it will surely be
easier to attract new ones?
All I ever hear is "once we have a proper design, we will..." (be able
to improve performance, attract more developers, whatever), and I simply
don't believe these claims. As I said before, where are all the Java
experts flocking to JOSM-NG because of its clean design? As I said
before, it would only take a few Java Expert man-days to get JOSM-NG to
"fly".
JOSM is currently designed in such a simple fashion that I can honestly
ask someone who is only a C++ or Ruby or whatever programmer to
implement features. I fear that once I've let the Java crowd have their
way, this will be much harder. This would not be a problem for JOSM if
the Java crowd were big enough and there would be a realistic hope of
them taking over the real work but honestly, I don't see it. Without
wanting to go into personalities too much: If you look what Dirk has
done during the last two months. He was new to JOSM two months ago,
threw himself at the job without a lot of encouragement from anybody,
without whining about what JOSM is - simply starting to make it better
step by step. He went through the tickets in trac, cleaned up there,
asked me for help where he needed it (not that he needed a lot), started
improving JOSM on a number of issues. I'd rather have ONE person like
Dirk than TWENTY people telling me how they would like to contribute but
unfortunately cannot because they don't like JOSM's design.
(And if now, after spending a lot of time with JOSM and doing really
useful stuff, Dirk would come along and say "we need to throw this and
that over board and refactor a bit" then I'd probably not complain for a
second because I know that he's not doing it for beauty but to get his
work done. Heck, he probably wouldn't even ask me...)
> Again, I mean, if you wouldn't categorically refuse changes to the
> overall JOSM design, where *could* the JOSM architecture already be today?
I have said, more than once, that I'm absolutely open to design changes
as long as they're connected to a specific goal ("I have to change this
in order to be able to implement that"). What I won't accept is design
changes as an end in itself. I know Imi's not around to defend his
design choices but please be reminded that Imi is a Java developer who
*knows* exactly how things are "usually" done and who has chosen to
implement JOSM as we see it *for a reason*, and not out of ignorance.
I'm not saying this is set in stone but I'm also unwilling to offer JOSM
as some sort of playground where people may play out their design fetishes.
Bye
Frederik
_______________________________________________
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
