1. Question: What is OpenSG, what is the goal of OpenSG?
  2. Question: Should this be done on OpenSG 2.0 or OpenSG 1.8?
  3. Issue: Communication problems
  4. Issue: Roadmap and direction
  5. Issue: OpenSG 2.0 development languishing
  6. Issue: Development organization
  7. Issue: Relatively few contributors

This page has been split into subprojects (see Dev/DevHome). Now it mainly concerns developer communication issues.

Question: What is OpenSG, what is the goal of OpenSG?

Please see wiki:OpenSG2Vision for this.

Question: Should this be done on OpenSG 2.0 or OpenSG 1.8?

Allen: I think we should concentrate on these things for the 2.0 system. We don't need or want to hold up the 1.8 release to get these things corrected. Let's get 1.8 out the door and then start diving full-on into 2.0 development and correcting all these issues. 2.0 is where we are going to be competitive anyway so lets get it going faster not slower.

Issue: Communication problems

  • GV: "I don't know why but this seems to be the major issue. Even with all the tools around we never seem to be able to utilize them to more than 5% of their potential."
  • Communication is key for many of these issues: roadmap, development, documentation, marketing, organization.


  • Silver-bullet tools: Trac, wiki, mailing list???
  • Probably boils down to making a more direct effort at communicating and coming to an agreement on common things (roadmaps, direction, features, timing, etc)

Issue: Roadmap and direction

  • No roadmap describing what needs to be done and who is working on it.
  • Many things never get completely done. (FLT loader, experimental code)
  • A shared roadmap is important for two reasons. Users need to see where the project is heading and developers need to agree on where the project is heading so they know what to work on. This is key to keeping the project moving forward and maintaining inertia. It is also a great way to get new contributors because it can help them be interested in what is going on and what they can work on.
  • For many developers, OpenSG is not their "day job". This can make it tough to decipher how much time can be spent in development and when.


  • Develope a roadmap. :)
  • Develop wishlists and try to merge them into a coherent roadmap.
  • Use trac tickets and milestones to help with this.
  • Create pages with "simple" projects for new people and "large" projects for experienced people to help contribute.
  • Discuss, refine, and agree on future direction. Once we have that, document it and stick to it.
  • Try to get people to commit to what they are willing to do and when they will do it.
  • Create development discussion pages on the wiki to keep the vision clear and to document conclusions and direction.
  • Feature request pages and tickets.
  • OpenSG development not being a "day job" for many developers is true, but IMHO that doesn't mean we can't have people estimate how long they thing it will take them to do something and then use that estimate to keep milestones on track. If we don't have some type of estimates and accountability to those estimates, then development will continue to flounder.

Issue: OpenSG 2.0 development languishing


  • Move over to developing on OpenSG 2.0 ASAP
  • Start practicing "Release early, release often". We need to release more often and get new features in and used more quickly. This is a key to promotion and dissemination of the technology.
  • Move fcdProcess over to python. #53.
  • Finalize or at least get discussions going again about the fc core and alternative ideas.
  • Get people involved!!!

Issue: Development organization

  • Currently the first problem somebody interested in contributing has to solve is to pick the right person in the fuzzy cloud of involved individuals doing OpenSG. And more than once I heard, 'oh I talked to xyz about abc and it somehow never got anywhere, didn't you know'.


  • Have subsystem maintainers and break development up along subsystem lines

Issue: Relatively few contributors

  • The OpenSG team does have a good number of people adding code, but it is not as large as it could be.
  • This is greatly tied to the lack of promotion. We can't expect to get developers if we don't get users. And we can't get users if we don't promote the system and tell them about it.
  • Extension is too difficult.
  • Create list of potential projects (see: ProjectIdeas)


  • Make it easier to extend OpenSG 2.0 and document the process. (see Dev/Building & Dev/Documentation)
  • Open up the write access to the repository a bit and let people help on small things (documentation, examples, etc) before moving onto larger items.
  • Bring them in, build their skills, build the community.
Last modified 8 years ago Last modified on 01/17/10 01:11:44