[Gvsig_english] gvSIG 1.9.1

[Chris Puttick]

----- "Miguel Montesinos" <mmontesinos at 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?

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.

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.

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 ).

Regards

Chris

-- 
Chris Puttick
CIO
Oxford Archaeology: Exploring the Human Journey
Direct: +44 (0)1865 980 718
Switchboard: +44 (0)1865 263 800
Mobile: +44 (0)7908 997 146
http://thehumanjourney.net


------
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.