El lun, 29-03-2010 a las 13:27 +0000, Chris Puttick escribió: > ----- "Miguel Montesinos" <[email protected]> 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? >
The stabilization process has been explained in the last mail of Jorge Sanz. The aim is to distribute a tool that is reliable in a professional environment. > 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. > Of course there's not a bug-free product, but we have to try to assure that (at least) the product doesn't cause any loss of data when managing users information. The history of free soft is full of FUDs, and culture of oportunism and amateurism so we think that our efforts to release a quite stable products are a must. > 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. > Many groups have developed their extensions or have generated their own distributions. If they want, theycan put them on the contributions catalogue, or if there is commitment and the aim, try to add it as an official extension of gvSIG. It's also valuable that those groups haven't used the gvSIG brand to cause a situation like this, where people ask about a fork, with confusion between the official version and yours, and where the leaders of that fork create a climate of opinion to justify the need of a fork. I sincerly think that is really irresponsible and unsustainable. I don't want to think on an scenario where we have five companies, where every one of them releases their own *gvSIG XXX*, *gvSIG YYY*, etc. demanding a special treatment in order to avoid a fork. > 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 > ). > About the offline discussion, several member of thegvSIG team, from the organizational part but also from the technical side have tried to contact with OA. Sometimes, from the organizational part we haven't received any answer. The aim of the contact was to try to collaborate on the gvSIG development. The off-list mails sent from the organizational team weren't answered. From the off-list mails sent to collaborate on the technical side, we received from OA a proposal to work for gvSIG 2.0 completely oriented to maintain their fork. These issues, with the thread of mails started last Friday by OA team, drive us to considerate more appropiate to maintain the debate in public, in order to let the community to express their opinions and impressions. >From our side, we admit and will admit all the errors we made and for sure we will make, but we don't have any doubt about the spirit of collaboration and commitment with free software is in the DNA of the gvSIG project. Regarding the interesting book you comment, just note that this book is a free document and can be obtained here: http://producingoss.com/. As the front cover of this book states, from gvSIG project we will always try that all the *arrows* go on the same direction. Regards Gabi > Regards > > Chris > -- Gabriel Carrión Rico Director del proyecto gvSIG Responsable Grupo SIG - CAD Conselleria de Infraestructuras y Transporte Generalitat Valenciana Valencia - España http://www.gvsig.gva.es _______________________________________________ Gvsig_internacional mailing list [email protected] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
