No subject

the chance to jump on a train that so many passengers are on that they will
even push it to its destination when the engine stops.

I think you should not underestimate this aspect. For me to read words of
the central scrutinizer lining out what goes and what does not might be a
reason to skip gvSIG, even if I'd prefer it from a technical point of view.

I'd be able to fork in some 30-40k=E2=82=AC for software development.
Do get back to work and convince me.

And forgive me for my English.

Gismael

-----Urspr=C3=BCngliche Nachricht-----
Von: gvsig_internacional-bounces at listserv.gva.es
[mailto:gvsig_internacional-bounces at listserv.gva.es] Im Auftrag von Chris
Puttick
Gesendet: Montag, 29. M=C3=A4rz 2010 18:43
An: Users and Developers mailing list
Betreff: Re: [Gvsig_english] gvSIG 1.9.1



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

> Hi Chris,
>=20
> >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=20
> product?
>=20
> I refer you to Jorge G. Sanz's mail to this same list, just a few=20
> minutes before your post. Surely you were writing your message when=20
> Jorge's one was sending his.

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

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

Optimised quality is good, but there has to be a balance between the produc=
t
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.
=20
> > What sort of organisations believe that a beta/unofficial version of
> a product is inherently less stable/usable/bug-free than an official=20
> non-beta official release? I have to ask, albeit "tongue in cheek",=20
> because there's a long history in IT of there being no connection=20
> between the stability/bug-count of a product that has been officially=20
> released v. ones that stay in beta.
>=20
> If so, why don't people just release their beta versions? An official=20
> version is not bug-free, but I'm sure you're pulling my leg if you try=20
> to sell out that beta versions are the same than official versions. I=20
> know several public administrations (for instance) that wouldn't allow=20
> an unstable version to be deployed over hundreds of thousands of=20
> 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 yo=
u
need to change it a little and often, be less about control through
committee and policies and more about controlling the edges.

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

I guess it is about levels of quality being desired. As a non-developer use=
r
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 a=
s
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.

>=20
> > 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=20
> installation very simple. This is why Ben was able to spend so much of=20
> his time making the OADE versions of gvSIG.
>=20
> I understand your requirements. We'd just like to see Ben working=20
> close to our developers in the same repo and so on. I assure that our=20
> developers also spend a lot of time working on gvSIG. Don't duplicate=20
> 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=20

>=20
> > I fully understand that the core of gvSIG development has specific
> sponsors with specific needs, and that those needs have to be met. Our=20
> needs are different and a degree of urgency is one of them, hence=20
> gvSIG OADE. Maybe this discussion should be taken off-line; I would be=20
> happy to discuss at length with both the core team and the sponsors=20
> the non-technical reasons why gvSIG OADE had to exist and my views on=20
> the basis for successful open source development (which are broadly in=20
> line with Karl Fogel's=20
> http://www.amazon.com/Producing-Open-Source-Software-Successful/dp/059
> 6007590
> ).
>=20
> I know Karl Fogel's book, as well as some members of gvSIG do. We are=20
> open to further discussions, and we would like to have them in order=20
> to avoid actual gvSIG problems, but I disagree it should be made in a=20
> closed way. Weren't you asking for transparency? Let the community be=20
> aware of our oppinions. Be sure that gvSIG will allways embrace=20
> contributors and collaborations from the community, we'd like to have=20
> more and more, so please use this public space to let others know=20
> what's going on and give their oppinions.

I was offering the private discussion because I would like to see a paradig=
m
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.

>=20
> So, please feel free to express your non-technical reasons why gvSIG=20
> OADE should keep existing as a =C2=BFdistribution/fork? and share your=20
> 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 need=
s
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 tha=
t
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 hav=
e
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, releas=
e
often. The open part can be challenging with a primary sponsor with specifi=
c
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.

>=20
> >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/>
> >
> >
> >------
> --------------------------------------------
>=20
> Miguel Montesinos
> CTO
> Prodevelop
> Tel: +34 963510612
> http://www.prodevelop.es
>=20
> _______________________________________________
> 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 Documen=
t
Format). If you have difficulty opening them, please visit
http://iso26300.info for more information.

_______________________________________________
Gvsig_internacional mailing list Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


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