I revisited the future of OpenSG discussion and pulled out the parts that are not simple tasks but are instead discussions that need to be had about workflow, process, or development philosophy. (as everyone replies to these, it may make more sense to split each point off into it's own reply thread for discussion.)
1) What is OpenSG and what is the goal of OpenSG. Dirk has said: "The goal of OpenSG is to be a widely, used self-sustaining Open Source scenegraph system for a wide variety of applications. We're not focusing on one application area, the system should be general enough to be able to handle a wide variety of things. The design goal is to provide an abstraction of the complications of the underlying graphics hardware and software systems for the user to simplify use of advanced graphics systems and algorithms. This means that details about multi-pass algorithms, shader composition, multi-threading and clustering should be hidden as far as possible." Does everyone agree with this and what implications will this have. For example if we say that we want it widely used, then we may need to spend time on features that the core developers don't need but users do. We may also need to spend more time on demos and documentation. 2) What should be done on OpenSG 2.0 vs. OpenSG 1.8? Or when should all development switch over to 2.0? I think we should concentrate all development effort on 2.0. 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. 3) How can we address communication issues in the project? GV said: "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 other issues: roadmap, development, documentation, marketing, organization. How can we improve communication and coordination in the project? I think it probably boils down to making a more explicit effort at communicating and coming to an agreement on common things (roadmaps, direction, features, timing, etc) and making sure there is leadership in place to keep everyone coordinated. Other ideas to help would be things like use Skype to host meetings of the developers every 2 weeks or so, have development "sprints" every couple of months where everyone devotes a few days at the same time to really push things forward. 4) Roadmap First question here, is does everyone agree that we need a roadmap? Will it work? Are there cases where it will not? At least as it looks to me right now there is no coordination between different development efforts. I don't think any of the core developers really know what each other are working on or are about to commit. For example I have seen Dirk surprise GV and I have seen Andreas surprise everyone with new features and changes. This is not all bad (I like new features) but is there a reason that it has to be like this? Without a roadmap describing what needs to be done and who is working on it, many things never get completely done and no planning really happens. 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. I know that OpenSG development is not a "day job" for many developers, 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. 5) Release early, release often and feature demos/examples This is one of those points I have been harping on. I don't think OpenSG promotes itself at all and there is not anything world visible that shows all the great work going on. If no one uses the code, then it is really as if the work never happened. I was talking to one of our customers last week. We use OpenSG for all their projects but they are uncomfortable with that and he made some interesting comments. Regarding the website: "The impression it gives is that it is dying". Regarding OpenSG: "The other major scene graphs seem to be more in the open and active" I don't think this is true, do you? Are we willing to change this perception? To make it happen I think we need to use the roadmap (see 4) to push development forward with more focus. Release much more often. And every time there is a new feature add an example to the source tree, make sure that example is in the nightly build, and then announce the new capability everywhere an point to that example. I see this last point being the controversial one. Is every developer willing to add an example/demo of every significant new feature they add and make this part of their normal development workflow? If we can't get everyone on board with this then I think it is a non-starter. 6) Leadership and direction Please don't take offense at this, but I think OpenSG has less direction then most other projects. Lack of direction usually points to a lack of leadership. If a new user looks at the OpenSG mailing lists I don't think they could pick out the leader or leaders. In my opinion, OpenSG functions using underground and muted leadership. This can work for very small groups that are co located, but I think it fails for large distributed projects. I know that this is an open source project so there can't be a project manager assigning tasks and telling everyone to have feature X done by such and such a date or else, but that doesn't mean there still can't be leadership. Look at all the very successful open source projects and I think you will find a very active leader or leadership team at the core. This team doesn't do all the development work, but they provide guidance and direction to let others know what needs done and what are the priorities. They help guide the project by developing and maintaining the roadmap and priorities. OpenSG could benefit from something similar. I don't know if it could follow the Apache model with voting or the Python/Linux model with a benevolent dictator, but it is clear to me that something is needed. There needs to be a some form of centralized leadership to make decisions and point the way forward. Am I just crazy or do other people see this as a problem too? Those seem like the top 6 from the discussion. If we can get agreement on these issues it should do a great deal to get the project on track and sprinting forward. -Allen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
