[Incubator] gvSIG project graduation
aanguix at gvsig.com
Thu Sep 10 12:43:42 PDT 2015
Thank you for your opinion. I think that this open an interesting
El 10/09/15 a las 16:01, Daniel Morissette escribió:
> Hi Alvaro,
> Thank you for your detailed response. I have to admit that what is
> happening here with your TSC turning into staff performing day to day
> project management is setting a precedent and I'm not sure what that
> means for OSGeo's incubation criterias.
> Can you please provide more details on what you mean by "that part was
> reviewed and accepted already"? Do you have links to emails relating
> to that? Once a project enters incubation, the next formal acceptance
> step is the graduation which is what we are discussing today. There is
> no intermediate acceptance step that I aware of, so I'd like to know
> why you think part of the checklist has been accepted already.
Yes, of course, I can look for those e-mail... although as the process
has been delayed so much time. I don't know if it's important, but I'll
see if I have them...
I remember that before last International gvSIG Conference where a
comment was made precisely about the development issues that were
pending to review. Even that if we did it at that moment it would be
perfect to be announced at the 10th International gvSIG Conference. At
that moment we were very busy with several tasks about gvSIG 2.1 and we
told that it wasn't possible, and when we could we would do it.
If it is necessary I can make archeology in my e-mails.
> My personal reaction would be to ask to have the checklist reflect
> today's reality with respect to the TSC and decision making, but I
> don't want to cause you to do extra work until we hear from other
> Incubation committee members on this question.
It's not an extra work. It is to summarize the previous e-mail.
Sure I will spend more time completing doubts and opinions that you are
> Also, having staff perform the day to day management of the project
> through face to face discussion may be more efficient (I have no
> doubts), but that doesn't directly meet the "Open decision making
> process" expectations that we have put on all other projects so far,
> so the Incubation committee will have to decide on how we deal with
> that. Do we treat gvSIG as an exception, or decide that open decision
> process is no longer a requirement? And if we remove that requirement
> then how do we distinguish between a private company just pushing its
> source code to the public and a project managed the way gvSIG is managed?
I think I'm going to encourage the discussion... although I don't know
if it's an objective at this mailing list. In any case, I think it can
be interesting to explain the gvSIG point of view.
I think we have different points of view. Professionalism doesn't go
against transparency. In the opposite interpretation... I think we do a
big favour to the proprietary software.
I think there's a misinterpretation about the objective of the
professionalism of an open source software. In a lot of conference we
speak about this precisely.
And our opinion can be summarized in the sentence: “It's good that
people collaborate voluntarily with an open source project, but we want
that people can work from Monday to Friday on open source software,
professionally, and in their free time they do whatever they want (if
they want they can provide to an open source software voluntarily)”.
Besides this is a typical argument of the FUD: professional teams in
proprietary software, and voluntaries in open source projects.
We think that it's a milestone that gvSIG has got to keep a professional
structure... and I never wouldn't see it as a default.
Making decisions every day is logical. We speak about decisions that,
besides, only affect to the core of the project (and in gvSIG 2.x, the
core is a minimum fraction of gvSIG).
An example of day-to-day decision, and made today: In gvSIG, until now,
when a shapefile is created by scripting, it has to be declared if it is
2D, 3D, 2DM, 3DM (M is related with dynamic segmentation). A change has
been decided for gvSIG 2.3, where if nothing is said, it's 2D. And it's
a change at the core.
Does anybody think that an expert committee has to meet to decide these
And in any case, decisions that affect to the future and evolution of
the project are made by all the persons/entities (really the persons
usually work in entities) that are involved in the gvSIG development.
Decisions are made between all the involved people, not in a one-sided
way. That information is made public. I don't see what's the difference
with the OSGeo guidelines. In fact that way to work, as I said, is more
democratic and transparent than the board meeting and the publishing of
a minutes that anybody reads.
We have worked with two systems, and in our case, now is more efficient.
But summarizing this long answer...I don't see that this contradicts
anything of the specified that a project must achieve.
> The reason for the open decision making process is to make it easier
> for new external contributors to join the day to day management of the
> project and by the same way increase the project long term viability
> by preventing the dependence on staff from a single organization.
Of course, and because of that any important external contributor -I
would remove “external”-... any important contributor can become part
(and in fact they do it) of the decisions making.
Of course...if anybody add a functionality through a plugin or script in
an exceptional way... I don't include him in this group. I'm speaking
about persons/entities, involved in a more or less continuous way in the
And... I hope new persons became part of the project day-to-day, they
are welcome. But being sincere, does it happen? I don't think in it, I
don't think that a person dedicates the 100% of his time to a project
voluntarily. He/she can dedicate partial time depending on their
professional needs related to the project. In this case, depending on
the case, and as it has been commented, he/she can become part of
In any case, the answer to this paragraph is related to the previous
one. Existing of a professional structure (to work daily). And here I
think we can speak about the gvSIG Association, because you are
referring to it as “single organization”.
The professional structure is part of the gvSIG Association, that is an
association of several companies, members and collaborators, and
non-business entities that provide public support to the project.
Entities that provide economically to the association to support that
professional team. And they support because the gvSIG Association
generates a business model around the free geomatics (not only gvSIG)
that becomes a mutual profit.
Association that any entity that want to join to, and achieve the
regulations, can do it.
It's very different to a “single organization”. In fact, it's the
guarantee that the project won't be managed by an only organization,
with the risks that it implies (including the extinction), besides being
a safeguard against the multinationals that try to approach open source
projects with business intentions typical of the proprietary software.
If we study other open source software projects, including geomatics, we
can see that other projects became a failure precisely because they only
dealt with the technical part, and a sustainability model wasn't started
up in order to guarantee its continuity.
It will be a long e-mail
> For instance, several years ago I was the mentor for the MapGuide and
> later on the FDO projects and we worked hard with them to move the
> decision making from face to face discussions inside Autodesk offices
> to the respective project mailing lists in order to open up to the
I don't know the Mapguide model. And with humility, I think it's a
project with low impact. And speaking of impact as implementation of a
business model that allows to offer an alternative to the multinationals.
I think we have to reflect on this kind of things in OSGeo, if we really
want to be an alternative to the proprietary software... in a
professional level too.
Although that's true, it's not very related to the incubation.
> Sorry for the long email. I'd like to hear what other IncCom members
Ha, ha. No, quite the opposite. And I think my answer is longer
> On 2015-09-10 6:20 AM, Alvaro Anguix wrote:
>> Hi Daniel,
>> El 10/09/15 a las 04:12, Daniel Morissette escribió:
>>> Dear All,
>>> I started looking into the gvSIG incubation checklist at
>>> http://wiki.osgeo.org/wiki/GvSIG_Incubation_Checklist and am having a
>>> hard time tracking down info about the Technical Steering Committee.
>>> The checklist points to
>>> http://wiki.osgeo.org/wiki/GvSIG_Technical_Steering_Committee which in
>>> turn points to two broken links for the
>>> [https://gvsig.org/web/working-groups/organizacion gvSIG TSC front
>>> page] and [https://lists.forge.osor.eu/listinfo/gvsig-desktop-tsc-pub
>>> public mailing list]
>>> Can you please review the Incubation Checklist page (and the pages
>>> that it links to) and make sure all links are working? I'd like to see
>>> archives of the TSC mailing list showing that decisions are indeed
>>> made in an open manner and in collaboration with the community on a
>>> public list and I cannot find that at the moment. I managed to find an
>>> old TSC archive at
>>> http://joinup.ec.europa.eu/mailman/listinfo/gvsig-desktop-tsc-pub but
>>> the most recent posts date from 2013.
>> Thank you for the feedback!.
>> You are completely right. In its day, that part was reviewed and
>> accepted already, so we complete the reviewing tasks that were pending.
>> And right, there has been enough time to evolve the management of that
>> Such was the case that we didn't pay attention to these links, and with
>> the new gvSIG website (<http://www.gvsig.org/>www.gvsig.org), to consult
>> the contents of the old website, the text “docs” has to be added to the
>> URL. For example, the link
>> With the advance of the project we have been correcting issues that we
>> think they make us to be more efficient. Efficient in the meaning of
>> eliminating the bureaucratic parts and speed up the decision making. It
>> has also been possible, in a big part, thank to the professional
>> structure of the project who works daily for the project. It can be
>> different to other projects. It makes that the day-to-day decisions can
>> be made by people of the professional structure (there's an architecture
>> and development manager, and a product manager). The efficacy has been
>> notable, and having a meeting every week to make small decisions didn't
>> make as much as sense. It is thank to the professional structure that
>> can dedicate all the time to gvSIG.
>> And the TSC, that is composed of the main developers that are working on
>> gvSIG, has a meeting after every final version in order to make
>> decisions for the next version. Currently it is planned to release 2
>> versions per year (one version in May and another one in December),
>> although this year it has been an exception because we will release
>> three versions (gvSIG 2.3 will be released in December). At that meeting
>> it is decided what to work on for the next version. For example, for
>> gvSIG 2.3, the next version, it's panned to make the effort to have a
>> first distribution for MAC OS X and Windows 64 bits. It involves to
>> change libraries for raster accessing and projections mainly... and we
>> are working on it now.
>> And instead of having proceedings, we preferred to advance one more step
>> and publish the decisions publicly, because the proceedings are not read
>> by a lot of people. Concretely in our blog. At this way, following the
>> example of gvSIG 2.3, we announced that decision (this is the link in
>> English but it was published in Spanish too):
>> Of course it doesn't mean that gvSIG includes only these changes. We
>> have to include all the possible functionalities developed by the
>> community that are integrated with that version (but it's out of the
>> initial planning and the gvSIG scope of decision).
>> And there's also some decisions about some objectives at these meetings
>> that are not carried out at the next version. It is listed at the gvSIG
>> redmine, at the “whislist” option -the access to this list is also
>> *In summary:*
>> We can correct these links, adding “docs”, but it wouldn't make much
>> sense because now we work in another way, although it was reviewed then.
>> It's another way that I think it is more open and agile.
>> We would be able to summarize the information of this e-mail and add it
>> to the checklist.
>> And thank you again for reviewing our job!
>> Alvaro Anguix
>> gvSIG Association
>>> On 2015-08-11 1:07 PM, Jody Garnett wrote:
>>>> General call out to the committee to help review on this one :)
>>>> Jody Garnett
>>>> On 28 July 2015 at 04:27, Dimitris Kotzinos <kotzino at gmail.com
>>>> <mailto:kotzino at gmail.com>> wrote:
>>>> Dear all,
>>>> I am happy today to report to the list that the gvSIG project has
>>>> fulfilled in my view all the criteria put forward by the OSGeo
>>>> Incubation Committee and as the project mentor I support the
>>>> request for graduation.
>>>> gvSIG is one of the healthiest and very active projects around,
>>>> with a
>>>> solid developer and user base. It has been around for a long time
>>>> has done excellent things, the latest being an award at the NASA
>>>> Wind contest received in FOSS4G-Europe in Como, Italy this month.
>>>> I had the chance to meet with the gvSIG people at FOSS4G-E in
>>>> Como and
>>>> we finalized the checklist for the project graduation. You can
>>>> find the
>>>> checklist here:
>>>> The people around gvSIG have responded greatly to all the
>>>> requests I
>>>> made as a mentor, they have gone even beyond that in many
>>>> e.g. by providing live statistics on their developers' activity.
>>>> They have gone through a code provenance review, they have user
>>>> developer lists in many languages and they have in place
>>>> practices that abide with what I would consider proper
>>>> governance of
>>>> open source projects.
>>>> I would like to ask the list to take the time and have a look
>>>> to the
>>>> checklist mentioned above and if anything is found out of the
>>>> please let me and Manuel Madrid <mmadrid at gvsig.com
>>>> <mailto:mmadrid at gvsig.com>> know.
>>>> I would also like to ask Jody to initiate the proper time
>>>> period for
>>>> comments and declare the time for voting when the time comes.
>>>> Finally I would like to thank Manuel and Alvaro from the gvSIG
>>>> Association for their excellent collaboration and to publicly
>>>> to them that sometimes the work load prohibited me to be as
>>>> and responsive as I would like.
>>>> Thank you for your attention,
>>>> Best regards,
>>>> P.S.1: Although the project has made a great effort to provide
>>>> documentation for ... everything, some things might be found in
>>>> (their language of origin), as well as some of the most active
>>>> lists are
>>>> the Spanish ones. I respected that and I let the project take its
>>>> and decide by itself on what to translate and what not.
>>>> But I would like to say kudos on their efforts to provide
>>>> everything in
>>>> at least both Spanish and English.
>>>> P.S.2: Since during the process we had to switch from the
>>>> v.1.0 to v.2.0 of graduation requirements I was wondering what is
>>>> proper way to introduce comments and requests for changes for
>>>> Dimitris Kotzinos
>>>> Head MIDI team
>>>> Lab. ETIS (ENSEA/UCP/CNRS UMR 8051)
>>>> & Dept. Sciences Informatiques, Université de Cergy-Pontoise
>>>> 2 av. Adolphe Chauvin
>>>> Site Saint Martin, bureau A561
>>>> 95000 Pontoise
>>>> phone: +33 13425 2855
>>>> e-mail: Dimitrios.Kotzinos at u-cergy.fr
>>>> <mailto:Dimitrios.Kotzinos at u-cergy.fr>
>>>> Incubator mailing list
>>>> Incubator at lists.osgeo.org <mailto:Incubator at lists.osgeo.org>
>>>> Incubator mailing list
>>>> Incubator at lists.osgeo.org
>> Incubator mailing list
>> Incubator at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Incubator