Hi Simon, All valid questions and I am sure they have been on several people's minds, so I will try and answer them (as far as I can) in some detail.
----- "Simon Cropper" <[email protected]> schrieb: > Hi, > > A recent post by Victor outlined the roadmap for Sextante. > > In it he indicated he intended to make Sextante into a library and > allow various developers to assimilate this library into their > projects, rather than maintain a plug-in system which requires > constant rejigging to ensure the bindings work. > Yes. This was at least in part motivated so that SEXTANTE could move on to use more recent versions of Java and stop wasting a lot of time worrying about backward compatibility. > Surprisingly, despite Victor pointing everyone to OADE 2010, the > developers of gvSIG (core project) were not goaded into a response. > > So I am asking... What is the position of the gvSIG Developers > regarding Sextante (you have had enough time to talk about this)? Are > you planning to incorporate the upcoming library into gvSIG or will > you let this plug-in languish? I suppose the question is also relevant > for the next version of OADE. > As far as OADE is concerned, we have decided, after some deliberation with Victor, to synchronize the release cycles of SEXTANTE and gvSIG OADE. So the final release of gvSIG OADE 2010 will come with SEXTANTE 0.6 as part of it. This is possible, because gvSIG OADE already runs fully on Java 1.6. > I think this is an important question as Sextante elevates gvSIG into > a product that can be used in a production environment; without it > gvSIG lacks important basic functionality. > > And at a personal level, I am in the final stages of preparing my > templates for my how-to manuals -- should I be writing my > documentation for OADE 2010 (which incorporates Sextante) or > gvSIG+Sextante or if the use of Sextante is uncertain, other upcoming > packages? I am also on record stating that gvSIG+Sextante is the first > FOSS GIS that I could use in a production environment. There is also > an upcoming paper in OSGeo Journal to that elk. So, will these > statements hold true in the future or will the gvSIG product fall back > to just the core modules? > I can sense some (warranted) frustration here. Indeed, the CIT gvSIG release policy, as much sense as it makes sense from an inside point of view, has violated one of the basic, "outside" rules of open source commitment: release early, release OFTEN. As the CIT developers are now focused on making gvSIG 2.0, the open source user community is faced with the following, bad situation: 1) The last release (1.9) with full functionality is not production use ready as it contains too many critical bugs and no longer runs the latest SEXTANTE. 2) The current code (2.0) has not yet been released as up-to-date binaries. And even when that happens, it is not clear how many of the extensions (not just SEXTANTE) will have to be updated to run on it and how long that is going to take. So in between, there is a big gap for a release that's bug-free enough for production use, runs SEXTANTE and includes all the other current extensions. This gap is where gvSIG OADE 2010 currently thrives! But bug fixes and SEXTANTE were not the only reasons why we made the decision to finally branch off gvSIG OADE 2010. We were also dissatisfied with some aspects of the user interface and with how some basic things, such as raster table legends, are handled. Since the development directions of gvSIG 2.0 are not exactly transparent (e.g. there was talk about a new way to handle external table joins on this list, but no details on how that new design looks), and gvSIG 1.9 was officially declared an abandonded code base (this has now changed with the chance of a 1.9.1 release), we eventually saw no choice but to branch. We have a growing production user base for gvSIG in our company and we owe it to them that they get frequent, stable releases of the software to work with. We did not take this path light-heartedly. Branching off of the main project is a very problematic move in open source development with the potential to both waste a lot of resources and split the community (both users and developers) -- some of the effects you are experiencing right now! So we really, REALLY hope that the 2.0 code line will allow us to re-integrate all the work that has been done here at OA and not force us to maintain our own branch any longer. There are good indications that this will be possible, but only if the development of new features and GUI designs gets more democratic. This whole thing is a learning experience for everyone involved. If you look at the history of other big projects that went open source, such as Mozilla or Star Office, you will realize that there were always problems like these in the start-up phase. I suggest, that BEFORE the 2.0 release, we have an open discussion on this mailing list to rectify things. The 2.0 release is the big chance to get it all right. Let's not blow it. Cheers, Ben > -- > > > Cheers Simon > > Simon Cropper > Botanicus Australia Pty Ltd > PO Box 160, Sunshine, Victoria 3020. > P: 9311 5822. M: 041 830 3437. > mailto: [email protected] > web: www.botanicusaustralia.com.au > > > > > _______________________________________________ > Gvsig_internacional mailing list > [email protected] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ------ Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
