[josm-dev] Refactoring of the JOSM architecture vs. Plugins

Frederik Ramm frederik at remote.org
Tue Aug 19 09:09:28 BST 2008


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




More information about the josm-dev mailing list