[Gvsig_english] gvSIG 1.9.1

Luis W. Sevilla lsevilla at sigrid.es
Tue Mar 30 00:38:06 CEST 2010


Gismael wrote:
> Ben,
>
> getting funny questions answered in zero time is the most convincing reason
> to consider os.
> So after seeing our current sw provider taking weeks of time answering
> serious questions, the fundamental direction is sorted out already.
>
> Without having gotten into details, I estimate that the spanish authority
> which has launched gvSIG has made use of EU funding for its project
> accepting to make the outcome open source. What gives me the frown is to see
>   
Sorry, but these is not the way it worked. Spanish regional ministry 
started with there internal funds a free software GIS development, and 
at the end of second year regional government assigned EU funds.FLOSS 
was an internal requirement,
gvSIG development started after a migration project study [1] (sorry, 
report only in spanish), and in the context of a project for migrating 
[2]all and every software system of the Transportations and 
Infrastructures Regional Ministry of Valencian Region.
> it half way between completely community-developped Qgis and lets say uDIG,
> thus being forced to make it available to the public but also forging it
> into the preferred direction.
>
> Keep  it open, make it lively and give me plugin repositories that overwhelm
> me.
>
> By the way: explaining that in comes from Spain, is available in about 15
> languages, having a British developped branch with the best German
> translation available made sceptics somewhat interested.
>   
Was multilingual by nature, because Valencian region it's bilingual 
(officially). English was an obvious choice, and we added as much 
languages as volunteers wanted to contribute from his national (or 
mother) language translation/corrections. There are also a very active 
Italian users community (and mailing list), and documentation repository 
[3] it's also multilingual, and offers a home for translations of every 
document (and also for community contributions).

Cheers
    Luis
> Gismael
>
>   
[1] 
http://www.gvpontis.gva.es/fileadmin/conselleria/images/Documentacion/migracionSwAbierto/DocConclusiones/CONCLUSIONES.pdf
[2] http://www.gvpontis.gva.es/cast/queesgvpontis/
[3] http://www.gvsig.org/web/home/gvsig-home/view?set_language=en
> -----Ursprüngliche Nachricht-----
> Von: gvsig_internacional-bounces at listserv.gva.es
> [mailto:gvsig_internacional-bounces at listserv.gva.es] Im Auftrag von Benjamin
> Ducke
> Gesendet: Montag, 29. März 2010 23:38
> An: Users and Developers mailing list
> Betreff: Re: [Gvsig_english] gvSIG 1.9.1
>
>
> Hi Gismael
>
> If you compare QGIS to gvSIG feature-wise, you will
> probably find, like we at OA did, that gvSIG is by
> far the more advanced and closest to "ArcView killer"
> of any open source desktop GIS projects.
>
> There are many strong open source GIS projects, but
> none as complete when it comes to interactive 
> functionality.
>
> Now, there have been some arguments about directions here,
> but nobody is willing to just walk away and feel offended.
> We WILL work this out.
>
> On April 1st, I will start feeding my modifications for
> gvSIG OADE back into the main SVN, most important bug
> fixes first. This will start the re-consolidation of the
> two code lines. Let's see how it goes. If there are no
> major issues, then version 1.9.1 will be a common code
> base again. If not, differences will be minor and it
> will be largely a matter of personal preference whether
> you go with the official gvSIG, OADE or any of the other distributions that
> may be around by then. I don't think choice has ever been a bad thing for
> customers (users).
>
> One last note: I am sure every closed source project has the 
> exact  same quarrels going on - behind closed doors. If those 
> go badly, then you will find out from the morning newspaper that your GIS
> vendor just folded. Just because you don't see it, does not mean things
> never get ugly at ESRI or MapInfo Corp.
>
> In an open source culture, we have the chance to discuss such things
> frankly, with no risks involved, and make sure to resolve issues before they
> get to breaking point; keeping everyone in the loop about progress being
> made.
>
> Isn't that preferable from the point of view of an investor looking for a
> sustainable option?
>
> Cheers,
>
> Ben
>
> ----- Original Message -----
> From: "Gismael" <gisme at lavabit.com>
> To: "Users and Developers mailing list"
> <gvsig_internacional at listserv.gva.es>
> Sent: Monday, March 29, 2010 10:35:08 PM GMT +01:00 Amsterdam / Berlin /
> Bern / Rome / Stockholm / Vienna
> Subject: Re: [Gvsig_english] gvSIG 1.9.1
>
> Guys,
>
> I'm just a end user without programming skills or ambitions. But right now
> I'm evaluating gvSIG vs. QGis for use in a real world productive
> environment.
>
> My proposal to change from GeoMedia to open source gave my bosses quite a
> shiver. Monitoring this list without any insight but mere curiosity and to
> get an idea what's going on in this project to help me find a decision has
> first let me think "hey, some public activity, at last" and then made shake
> my head realising that there seems to be some tribal ambush going on.
>
> Don't you think that if other potential users get this impression, too, it
> might scare them off and confirm prejudices against open source software?
>
> Even if I take into account that who pays the bill has undeniable privileges
> concerning the development of his project, I'd like to see some more ample
> based contribution to gvSIG, which (the contribution), by now, to me seems
> to be inferior to the above mentioned Qgis.
>
> From my point of view the fundamental advantage of using os sw is to 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€ for software development. Do get back to
> work and convince me.
>
> And forgive me for my English.
>
> Gismael
>
> -----Ursprüngliche 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ärz 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,
>>
>>     
>>> 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/059
>> 6007590
>> ).
>>
>> 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
>>     


-- 
Director Técnico / CTO
Sigrid - Grupo Acotelsa
Tel. +34 600 433 808
http://www.stereowebmap.com
http://www.sigrid.es 

The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends. (Ron Avitzur)



More information about the Gvsig_internacional mailing list