[Open-transport] What is an open format/standard (GTFS, etc.)

[Stéphane Guidoin]

>
> What would have to change about the GTFS change process, as defined at
> https://developers.google.com/transit/gtfs/changes, for you to feel
> comfortable saying is passed point #3?


1. The main comment would be about who is the editor of the spec. Usually
in a consensus based mechanism, the editor(s) of the spec is chosen by the
group as well as a "facilitator". Editors and facilitator can be replaced.
In the case of the GTFS, what I understand is that Google remain the main
editor. (although, you might argue that you don't see anybody with the
interest of spending some time maintain the spec, which is a valid argument
is some cases)

2. From what I discussed (and on this side I'm guilty of having heard only
one side of the story), the process is not so straight-forward since one
agency I discussed with felt that some changes they have asked for and were
supported by other players did not make it in the spec.

(Note : I used GTFS because it's the one that came in my mind, but in the
open data/format spec, several other format fall in the situation... in a
much worse sense)


On Thu, Jul 18, 2013 at 12:06 PM, Brian Ferris <bdferris at google.com> wrote:

> What would have to change about the GTFS change process, as defined at
> https://developers.google.com/transit/gtfs/changes, for you to feel
> comfortable saying is passed point #3?
>
>
> On Thu, Jul 18, 2013 at 5:55 PM, Stéphane Guidoin <stephane at opennorth.ca>wrote:
>
>> I am also spinning off a new thread from the "Open transport data tools"
>> thread since this point was a little off topic.
>>
>> At one point I said that GTFS is not an open format/standard and Brian
>> asked me to explain what I meant. Though the definition of open in this
>> context is not clear (and even what a standard is...), I wanted to clarify
>> what I meant (and hear some comments if any).
>>
>> For me, an open format in the context of open data should have the
>> following:
>>
>>    1. Freely available specs (probably obvious for everybody here)
>>    2. Use of open technology: No link with an existing implementation,
>>    no link with a specific development language or platform, no technological
>>    entry barrier, no patent related to it. (I guess everybody agrees on that
>>    one also).
>>    3. A clearly defined consensus-based governance (this is one where I
>>    will have less agreements). By that, I mean that:
>>    1. There is some sort of charter that explains how decisions are
>>       taken, mainly by "committee"
>>       2. Anybody can join the committee (paid membership is possible but
>>       should be low and allow for example non-profits or individuals to join).
>>       The charters should explain how people are joining, mainly if there are too
>>       many candidates
>>    4. Optionally, an open license should be applied to the spec (for the
>>    moment, I don't know any format governed by a open-licensed spec, but there
>>    are some discussions about this at w3c. Read this for more:
>>    http://berjon.com/blog/2013/04/w3c-open-license.html).
>>
>> The format does NOT need
>>
>>    - to be part of standardization body, until the governance is clear
>>    - to be *created* on a consensus based process. Adoption is mainly
>>    what defines a de facto standard. Once we reach a certain level of
>>    adoption, stakeholders should agree on the governance.
>>
>>
>> --
>>
>> From what I see, many formats fall short on point 3, for example GTFS.
>>
>> So why point 3. is important? Mainly because there is a strong risk of
>> lock-in for adopters when it does not work on a consensus. And this is bad.
>> It might not be bad _now_, but it can become in the future is some
>> organization feel that they are locked in. After that, they won't want to
>> engage in any non-officialized-ISO-like format.
>>
>> Also note that consensus does not mean that everything is accepted if a
>> majority agrees. The charter can define the target and the raison d'etre of
>> a format as well as a set of criteria (or an algo) to evaluate the
>> relevance of requested changes. So it we say, for example, that the raison
>> d'être of GTFS is publishing data, any request to ease internal operation
>> of agencies should not be accepted from the beginning while request to
>> improve fare calculation for trip planning would be evaluated. (that's a
>> little black and white, but I hope everybody gets it.)
>>
>> Steph
>>
>>
>>
>> --
>> Stéphane Guidoin
>> Director, Transportation
>> Open North
>> 514-862-0084
>> http://opennorth.ca
>> Twitter: @opennorth / @hoedic
>>
>> _______________________________________________
>> open-transport mailing list
>> open-transport at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/open-transport
>> Unsubscribe: http://lists.okfn.org/mailman/options/open-transport
>>
>>
>


-- 
Stéphane Guidoin
Director, Transportation
Open North
514-862-0084
http://opennorth.ca
Twitter: @opennorth / @hoedic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-transport/attachments/20130718/cda95822/attachment.html>