No subject


Mon Jan 11 14:18:06 CET 2010 

have
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=80 for software development. Do get =
back to
work and convince me.

And forgive me for my English.

Gismael

-----Urspr=FCngliche 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=E4rz 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
> product?
>=20
> 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=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
> 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 =
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.
=20
> > 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",=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
> 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=20
> know several public administrations (for instance) that wouldn't allow =

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

>=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
> installation very simple. This is why Ben was able to spend so much of =

> his time making the OADE versions of gvSIG.
>=20
> 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=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
> 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 =

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

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

>=20
> So, please feel free to express your non-technical reasons why gvSIG
> OADE should keep existing as a =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 =
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.

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

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

More information about the Gvsig_internacional mailing list