[Gvsig_english] gvSIG 1.9.1

Mon Mar 29 18:42:51 CEST 2010

----- "Miguel Montesinos" <mmontesinos at prodevelop.es> wrote:

> Hi Chris,
> 
> >De: gvsig_internacional-bounces at listserv.gva.es en nombre de Chris
> Puttick
> >Enviado el: lun 29/03/2010 15:27
> >Para: Users and Developers mailing list
> >Asunto: Re: [Gvsig_english] gvSIG 1.9.1
> >
> >----- "Miguel Montesinos" <mmontesinos at prodevelop.es> wrote:
> >
> >> >   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?
> 
> I refer you to Jorge G. Sanz's mail to this same list, just a few
> minutes before your post. Surely you were writing your message when
> Jorge's one was sending his.

Not quite, but Jorge's email was about the answer I expected.

> 
> >
> >
> >Does it result in a bug-free product?
> 
> Not at all. Software is never a bug-free product. It's just a question
> of trying to minimize bugs when you have almost 2 million lines of
> code. It's a fact that gvSIG does not achieve it completely, but our
> intention is to optimize quality, and IMHO sw quality needs a
> stabilization process. For sure our stabilization process can be
> improved, so we are glad to get new inputs.

Optimised quality is good, but there has to be a balance between the product being out there and the stabilisation process. If an infinitely long QA process results in bug-free code, is it good the product never gets released? There is also a balance to be struck earlier in the process; I think it is impossible in any software that can manage complex tasks in complex environments to be bug-free; you can continue to add ever more use cases and make the process of development ever longer and more expensive; yet still when you release users can find bugs, or disagree with feature implementations or on which features are in release and which not.

> > 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.
> 
> If so, why don't people just release their beta versions? An official
> version is not bug-free, but I'm sure you're pulling my leg if you try
> to sell out that beta versions are the same than official versions. I
> know several public administrations (for instance) that wouldn't allow
> an unstable version to be deployed over hundreds of thousands of
> clients.

They do release beta quality software all the time; some people label it as beta, some don't. For a long time in my profession it has been consider sensible to wait for service pack 1 or even 2 before adopting a new version of one major manufacturer's software. Maybe a definition of alpha, beta and release candidate is needed; in my definition beta is something that is believed to be stable in use but has known and maybe unknown issues.

Public administrations around the world are not famous for their effective use of information technology. The ones in the UK may be particularly bad, but in general public administrations have been unable to accept the truth about information technology and the fact that to get best value from it you need to change it a little and often, be less about control through committee and policies and more about controlling the edges.

> 
> >A stable product is one to which no changes are being made. A stable
> application is one that doesn't crash in normal use.
> 
> A stable product is one that the project team considers with a level
> of quality good enough to be released, with no critical (or the
> desired bug level) bugs. Of course it shouldn't crash.

I guess it is about levels of quality being desired. As a non-developer user of various software products, my personal contribution to the open source community has been about downloading and using beta (even alpha occasionally) products in real situations to see what they do and don't do and document any issues. With gvSIG I'm not able to help even in that way as I do not do GIS for my work. But if I was able to help in that way I don't see many opportunities to do so.

> 
> > 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 understand your requirements. We'd just like to see Ben working
> close to our developers in the same repo and so on. I assure that our
> developers also spend a lot of time working on gvSIG. Don't duplicate
> efforts is what I'm trying to communnicate.

I know that the core developers are working hard on gvSIG and have been for many years. But your motivations are maybe different, because of the your core funding and the nature of the organisation 

> 
> > 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
> ).
> 
> I know Karl Fogel's book, as well as some members of gvSIG do. We are
> open to further discussions, and we would like to have them in order
> to avoid actual gvSIG problems, but I disagree it should be made in a
> closed way. Weren't you asking for transparency? Let the community be
> aware of our oppinions. Be sure that gvSIG will allways embrace
> contributors and collaborations from the community, we'd like to have
> more and more, so please use this public space to let others know
> what's going on and give their oppinions.

I was offering the private discussion because I would like to see a paradigm shift in the way that gvSIG produces code and software releases and though it might be easier done in small groups, maybe by teleconference or even in person if I could arrange for it.

> 
> So, please feel free to express your non-technical reasons why gvSIG
> OADE should keep existing as a ¿distribution/fork? and share your
> basis for succesful open source development.

I'm sure not arguing for gvSIG OADE to be a fork or even an official distribution. We had needs, we worked for a while to try and get those needs met within the project without success, we took the code and made it something we could use. That's one of the many strengths of open source that we could do that. If it had been a closed source product we would have had to walk away. If version 2 comes out with all the features we need we'd change; we have no interest in competing, only our personal itch to scratch.

We have then tried to give something back by both giving detailed bug reports and making available our internal version for others to use. We have also, of course, been vocal supporters of gvSIG both on the list and in our sector.

There is only a few basic principles to a successful open source project in my belief. Keep the development open (all of it), and release early, release often. The open part can be challenging with a primary sponsor with specific needs and strong organisational culture.

Public administration and other highly risk averse CIOs can choose which release to deploy widely, which to keep to a small control group and which to ignore.

> 
> >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 <http://thehumanjourney.net/> 
> >
> >
> >------
> --------------------------------------------
> 
> Miguel Montesinos
> CTO
> Prodevelop
> Tel: +34 963510612
> http://www.prodevelop.es 
> 
> _______________________________________________
> 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.