[x3d-public] procedure for timely resolution of straightforward X3D specification issues
Michalis Kamburelis
michalis.kambi at gmail.com
Wed Feb 24 19:34:31 PST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160225/48cd7e0f/attachment.html>
More information about the x3d-public
mailing list