[Gvsig_english] gvSIG 1.9.1

[Gabriel Carrión Rico]

El lun, 29-03-2010 a las 13:27 +0000, Chris Puttick escribió:
> ----- "Miguel Montesinos" <mmontesinos en prodevelop.es> wrote:
> 
> > Hi Ben,
> > 
> > I'm not going into the origin of your fork decission. I'm sure *both*
> > gvSIG and OA have made some communication mistakes. A direct
> > communication would have avoided forks and time and resource wasting.
> > For sure at gvSIG we are pushing forward for external developers to
> > come in the project and join us.
> > 
> > Looking only at the future side, I encourage you to work together with
> > gvSIG people.
> > 
> > >   We just take the current gvSIG OADE 2010 sources,
> > >   fix the remaining 2 or 3 critical bugs and release
> > >   that as gvSIG 1.9.1!
> > 
> > It makes sense if we skip the stabilization process. The problem is:
> > Do we skip it? If so, can we call it a stable version? If not, who is
> > going to perform the stabilization process?
> > 
> > Maybe the stabilization process is not important for you, because you
> > have fixed those bugs, but for some organizations it's important, as
> > they cannot rely on a beta or unofficial version.
> > 
> > Would OA afford a stabilization process? If so, from gvSIG we can help
> > to teach how to do it.
> 
> What do you mean by a stabilisation process? Is the same sort of
> process that Microsoft et al would go through before releasing a
> product?
> 

The stabilization process has been explained in the last mail of Jorge
Sanz. The aim is to distribute a tool that is reliable in a professional
environment.


> Does it result in a bug-free product? What sort of organisations
> believe that a beta/unofficial version of a product is inherently less
> stable/usable/bug-free than an official non-beta official release? I
> have to ask, albeit "tongue in cheek", because there's a long history
> in IT of there being no connection between the stability/bug-count of
> a product that has been officially released v. ones that stay in beta.
> 

Of course there's not a bug-free product, but we have to try to assure
that (at least) the product doesn't cause any loss of data when managing
users information. The history of free soft is full of FUDs, and culture
of oportunism and amateurism so we think that our efforts to release a
quite stable products are a must.

> A stable product is one to which no changes are being made. A stable
> application is one that doesn't crash in normal use. We needed certain
> features functioning in gvSIG as soon as possible to make it usable in
> production, and in a way that made end-user installation very simple.
> This is why Ben was able to spend so much of his time making the OADE
> versions of gvSIG.
> 

Many groups have developed their extensions or have generated their own
distributions. If they want, theycan put them on the contributions
catalogue, or if there is commitment and the aim, try to add it as an
official extension of gvSIG. It's also valuable that those groups
haven't used the gvSIG brand to cause a situation like this, where
people ask about a fork, with confusion between the official version and
yours, and where the leaders of that fork create a climate of opinion to
justify the need of a fork.

I sincerly think that is really irresponsible and unsustainable. I don't
want to think on an scenario where we have five companies, where every
one of them releases their own *gvSIG XXX*, *gvSIG YYY*, etc. demanding
a special treatment in order to avoid a fork.

> I fully understand that the core of gvSIG development has specific
> sponsors with specific needs, and that those needs have to be met. Our
> needs are different and a degree of urgency is one of them, hence
> gvSIG OADE. Maybe this discussion should be taken off-line; I would be
> happy to discuss at length with both the core team and the sponsors
> the non-technical reasons why gvSIG OADE had to exist and my views on
> the basis for successful open source development (which are broadly in
> line with Karl Fogel's
> http://www.amazon.com/Producing-Open-Source-Software-Successful/dp/0596007590 ).
> 

About the offline discussion, several member of thegvSIG team, from the
organizational part but also from the technical side have tried to
contact with OA. Sometimes, from the organizational part we haven't
received any answer. The aim of the contact was to try to collaborate on
the gvSIG development.  The off-list mails sent from the organizational
team weren't answered. From the off-list mails sent to collaborate on
the technical side, we received from OA a proposal to work for gvSIG 2.0
completely oriented to maintain their fork. These issues, with the
thread of mails started last Friday by OA team, drive us to considerate
more appropiate to maintain the debate in public, in order to let the
community to express their opinions and impressions.

>From our side, we admit and will admit all the errors we made and for
sure we will make, but we don't have any doubt about the spirit of
collaboration and commitment with free software is in the DNA of the
gvSIG project.

Regarding the interesting book you comment, just note that this book is
a free document and can be obtained here: http://producingoss.com/. As
the front cover of this book states, from gvSIG project we will always
try that all the *arrows* go on the same direction.

Regards

Gabi


> Regards
> 
> Chris
> 


-- 
Gabriel Carrión Rico
Director del proyecto gvSIG
Responsable Grupo SIG - CAD
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - España
http://www.gvsig.gva.es