[x3d-public] procedure for timely resolution of straightforward X3D specification issues

[Michael Aratow]

Michalis:

Thanks for all of the outstanding comments.

Thanks also for recommending possible solutions!

And thanks for making great applications with X3D!!!

I think the only issue to consider is intellectual property.  As I see 
it, we are not trying to keep a */secret/* version of the developing 
spec from the public; it is really to protect the spec from getting code 
that has */secret/* intellectual property in it!!!

As far as I know, Khronos does have a similar intellectual property 
agreement, so we should talk to them about how they feel they can 
protect their standards from hidden IP encumbrance.

In regards to the membership fee, I wish we could just have free 
membership, but we don't have regular sponsors who can support the 
website, travel to conferences for marketing, legal fees, spec writing 
for ISO, marketing collateral, etc.

Thanks again,

Mike

On 2/24/16 7:34 PM, Michalis Kamburelis wrote:
>
> Thanks everyone for answering. Nice ideas (I still use classic 
> encoding daily!), good news about spec comments being in Mantis. 
> Leonard’s documents are great, reading them right now:)
>
> I thought about the “open GitHub” thing for a while. I want to 
> emphasize that I’m extremely grateful to all the people that helped 
> make X3D the standard it is today. Despite some issues, it’s still the 
> /best/ format for 3D data we have today, and it is open —- this is a 
> great achievement. And I benefit from this fact on a daily basis, when 
> developing my engine and games around X3D.
>
> At the same time, I want X3D to be more used by other people/software. 
> The fact that ugly unspecified proprietary formats like FBX gain 
> ground, and have sometimes better support in 3D authoring/rendering 
> software than X3D… well, it’s troubling.
>
> With this introduction done, let me try to make some constructive 
> comments:)
>
> 1.
>
>     I understand that the need to keep some things closed is necessary
>     for some members, for some issues.
>
>     At the same time, this is some barrier for the public contributions.
>
>     Compare this with open-source software development —- if you
>     /really/ want to welcome the community input, you need to make
>     your development public. This means making a /current/,
>     bleeding-edge, version of your software available for testing. And
>     this means opening a reliable channel to submit bugs/changes to
>     your stuff.
>
>     That’s why GitHub is so popular. Because it’s technology (GIT,
>     pull requests) promotes community contributions. (It’s not only
>     GitHub/GIT, of course. You can more-or-less say this about any
>     open-source software hub and version control system.)
>
>     Opening the membership to individual professionals, for a moderate
>     price, is a great thing… but it’s not the perfect world. Again
>     compare it with open-source software development —- if every
>     potential contributor would have to go through a “member” process
>     before even /seeing/ the development version of the software…
>     well, you would just have a lot less contributors.
>
> 2.
>
>     So, one idea how you could “have a cake and eat it too”:)
>
>     GIT and GitHub allow you to reliably merge changes, 2-ways,
>     between your repositories. So maybe:
>
>      *
>
>         Make a public repo “X3D spec in progress (without any
>         potentially-secret stuff)” on GitHub.
>
>      *
>
>         And keep secret (member-only) the “X3D spec in progress
>         (/with/ potentially secret stuff)”. When something “secret” is
>         ready to be made public (after all, it’s a necessary step
>         toward being part of the final X3D spec), then merge it from
>         “secret” to “public” repo.
>
>      *
>
>         And the big advantage: the public contributions could be
>         applied directly to the public repo. The public would have a
>         “current spec version, as much as we can show”, to comment on
>         and improve, in an open-source fashion (real issue tracker,
>         pull requests and so on).
>
> 3.
>
>     I know that many standards have been developed like X3D, or in
>     much more restricted fashion. As I said, welcoming input from
>     individual professionals, and offering them membership for a
>     moderate price (it’s 100 USD per year, as far as I see) is a
>     visible and very appreciated gesture.
>
>     But, maybe we can make it better? I found two examples of
>     standards (close to my heart and open 3D) that have specifications
>     openly available in GitHub, by Khronos:
>
>       * Vulkan : https://github.com/KhronosGroup/Vulkan-Docs
>       * glTF : https://github.com/KhronosGroup/glTF
>
>     I don’t know are these the “latest” spec versions of Vulkan/glTF,
>     possibly development on new spec features happens partially
>     elsewhere. But I know I can fork these specs on GitHub, submit
>     issues (bugs) there, submit pull requests (correction that can be
>     easily applied).
>
>     This is a great feeling, and I would love X3D to be such open.
>
> Thanks for reading:) Best regards,
> Michalis
>
> ​
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160225/d90f0801/attachment-0001.html>