[Gvsig_english] QUESTION gvSIG 1.9 (BN 1253) -- Future of gvSIG and Sextante

[Benjamin Ducke]

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" <scropper at botanicusaustralia.com.au> 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: scropper at botanicusaustralia.com.au
> web: www.botanicusaustralia.com.au
> 
> 
> 
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> 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.