I am surprised no one had any thoughts about the issues I raised in this e-mail. They are pretty core to OpenSG and IMHO if we as a community don't find a way to answer them the project not grow and reach its full potential.
Comments? Allen Bierbaum wrote: > 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 > ------------------------------------------------------------------------- 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
