Hello Jan, Jan-Oliver Wagner wrote: > On Thursday 08 February 2007 21:46, Sunburned Surveyor wrote: >> I spent the lunch thinking about what Stefan, Larry, and Jan-Oliver had been >> talking about. I have written a post on my OpenJUMP blog that gives everyone >> involved or interested in OpenJUMP something to think about. You can read >> the post here: >> >> http://openjump.blogspot.com/ > > good summary of the situation. > > One way out of the dilemma (or at least something that might help) is > to look at the professional users willing to pay and at the companies that do > receive contracts > for improving OpenJump (like Intevation did, though only for a tiny feature > so far). > Of course such contracts are typically feature-centric. The art of sustainable > Free Software is to take care for the base work out of these feature-driven > developments. One option is maintenance contracts for professional users. > This is successful for a number of Free Software products, but really > needs quite some time to take of -- and it is not possible to achieve this > for any product.
I think this requires a change in the attitude of the users, really. And by that I don't mean the single user, but rather institutions that are willing to pay less for a GIS, but somehow willing to pay. People haven't really learned to discern between free software and free beer. > Another option is that there are simply enough 'little' contracts, so that > those companies getting them are interested to take an active role > for the base work (you can observe this for UMN MapServer). > > The many JUMPs around make it difficult to get there. And it is especially > not in the interest of the professional users as they want to profit from > a consolidating core in mid-term. Features within a forked > JUMP are only cheaper in short-term view. Absolutely. One thing wrong in JUMP/OpenJUMP is the hard-coded configuration. By devising a way of configuring the application, we might bridge the gap between different versions. These versions differ on two aspects, basically: the GUI and the plug-ins/extensions they offer. I'm for central an OpenJUMP version, with basic plug-ins and with a developer-friendly way of defining a Setu up/Configuration file. > > Don't get me wrong - I've seen so absolutley great features in those JUMPs, > those guys do a really good job. > But I've not seen good rationale for the forks, except that it was easy to > start > since no discussion with other developers needed. Maybe thats one thing > OpenJUMP > should focus on: argue why a fork is suboptimal and concurrently offer help > to cope with keeping development a bit more stream-lined. > I know this is easily said while not offering to take over this job -- please > forgive me. > However, at least I will continue to make people aware of these facts ;-) > > All the best > > Jan > I agree with with, but who's got the resources to embrace the application and manage the project? As you said, most work is feature-driven, with paying users not realising that there's management and improvement work needed to be done. Cheers, Ugo -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 184960 fax ++49 +228 1849629 http://www.lat-lon.de http://www.deegree.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
