This is one big e-mail. I'm not sure how to begin answering it. From the top of my head:
* The roadmap needs to be there. At least something that we can look at and comment on. Direction for effort is also a good point in this. * A 1.8 end-game list needs to be made, so we know what needs to be done to get it released. Then work like mad on that. (There is work being done on 2.0 everyday, I'd prefer finishing 1.8 first.) What is left? * As said, we will use 1.8 for the current project (until march next year), then probably switch to 2.0 if it is stable enough. We need to know the status of 2.0 to know when to make the switch (and thus, if we need/can contribute to make things happen faster). * I agree with Dirk's comment that OpenSG is really in a sort of 'middle ground' with many users and too few contributing developers. Again, fixing the roadmap for 2.0 & setting tickets for everything 1.8 would help greatly. * I think IRC or anything text-based is better for conferences. That way, we also have a log of the discussions. But that's just me. (We seem to do pretty well here on the mail list, we just need faster iterations.) * Examples/Tutorials for new features are good. I think it would be easy to do since you at least need to test something that builds only within OpenSG that works with your new feature. Might as well put that up, extend and document it. * Leadership: Dirk-as-benevolent-dictator is ok. However, it seems as he does not have sufficient time to comment on all parts. Could we make a list of various parts of OpenSG where we have ppl with sufficient time & knowledge to provide leadership (or at least be the current 'point of contact' for communication), so that we have a clear map over which parts are covered and not. Each person would then be responsible to at least keep track of current status for her/his module and coordinate development. It need not be a single person, and could be the "mail-list forum" for some issues until we get more ppl commited. At least, the list of modules/areas, current leadership and current status should be summarized. (The PEOPLE file in trunk is a base for this.) This overlaps the roadmap work in some sense. I think the most important thing is establish where we are on the map and try to point out a heading to everyone. Cheers, /Marcus Allen Bierbaum wrote: > Dirk Reiners wrote: >> Hi Allen, >> >> Allen Bierbaum wrote: >>> 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. >>> >> They are complex issues that need serious time. I can't write an answer >> to that in a few minutes, and I haven't had enough time over the last >> week to really get into this. I took as much time as I could before my >> fiancee chops off my head to write this today , so take it with a grain >> of salt if there are rough edges. ;) > > We will do our best to make sure you keep your head. :) > > >>> 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. >>>> >>>> ... >>>> >>>> Does everyone agree with this and what implications will this have. >>>> >> I obviously agree. ;) >>>> 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. >> For example? > > I don't have an example right now, I was just asking more about the > philosophy of how development should proceed. Some projects become very > developer focused and forget about the users. If everyone agrees this > is not something we want for OpenSG, then we can make it so. > > (Some non-specific examples are: documentation, examples of new > features, simple extension, etc. OpenSG does well at some of this and > has problems with others) > >>>> We may also need to spend more time on demos and documentation. >>>> >> You seem to think that having more demos is a sufficient condition for >> getting more users and that having more users is a sufficient condition >> for getting more developers. I'm not so sure about that. I can see the >> users part, but for developers IMHO it's more important to have a system >> that is easier/better to work with/extend. I also think a good web site >> is at least as important as having demos. None of them are sufficient, >> though. I don't think there is a sufficient condition. > > Yes, you have seen a flaw in my logic. I am basing most of this on 2 > assumptions. > 1) Using the open source model of release early, release often has > worked for others so it will work for us. > 2) OpenSG is a development library so if we get users, then we get > potential developers. Just make the hurdle low enough for people to > contribute and we could end up with all sorts of nice stuff. See the > potential contributions page for examples. > > As far as more demos, that is for a different purpose that is related to > getting more users. Namely, promote OpenSG more often and more widely. > We have to make sure that people know that OpenSG is not only alive, > but is growing and adding features all the time. The marketer in me > sees this as key to getting new users and conversions from other > systems. Do others disagree or think that demos are not advantageous? > > >>>> 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. >>>> >> I am in full, total and absolute agreement on this one (did I miss >> something? Ah yes, complete! ;). > > Quick Poll: Are there any current users/developers of OpenSG that want > to keep using 1.8 for an extended time? If you are using OpenSG 1.8 > right now when do you plan to switch over? 2.0 alpha, 2.0beta, > 2.0release, 2.1, never, other??? > >>>> 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. >>>> >> Toolwise I think Trac is very nice and supports everything we need. We >> just need to use it more consistently. I would really like for everybody >> who finds a bug to open a ticket. Same thing for everybody who starts >> working on something, open a ticket, add it to the milestone/release >> that you think it will go into, and keep track of your progress in the >> ticket. If you find anything that is broken or doesn't work the way it >> should, add a ticket that describes it and maybe what ideas you have to >> change it. Some of these tickets might get closed quickly, or postponed >> to later releases, but having a record of it in Trac, together with all >> the other outstanding issues will help us keep on track. Make tickets >> for little things, too, so that they can actually get done and closed >> quickly. >> >> My main problem (and that has been the problem since the very beginning, >> and that's the general problem that every Open Source project has), is >> that I have 0 power to make anybody do anything. Everything that happens >> is done by volunteers in time that they either need to take of their >> spare time or that they need to free from their bosses. In addition to >> that the people developing OpenSG are smart, which is both a boon and a >> bane. The boon is that they do some amazing things, the bane is that >> other people (and people closer to them geographically and higher up in >> the food chain) have demands on them that can change quickly and >> unpredictably and that cut into their time (that includes me). > > I agree with using Trac. The only thing I have a slight problem with is > the idea of asking people to start a ticket for new things and then > combining that into the roadmap. I think it needs to be done the other > way around (within reason) > > I have a pretty simple (and possibly naive) suggestion here. > > 1. We make a webpage for each release/iteration (maybe the roadmap page) > 2. We make a list of things we know we want to go in and things we would > like to see worked on (Dirk and other leaders start the page and others > contribute to it) > 3. We prioritize the list a bit and turn the tasks into tickets > 4. People pick the tickets they are willing/able to work on and put > their names with them. If they can, they try to give a time estimate, > something like "done before the end of October" or something else simple. > 5. When a task is done, cross it off the list. When the tasks are all > done the iteration is ready to go. > > This is a very simple workflow and has very little overhead. It would > allow people to put in features that they or their company need that > others may not, but it also allows people to know what is coming and to > work together to plan the needs. > > It also gives new contributors a place to look for things they can help > with and it gives users a place to look to see what is going to be > worked on next and for what iteration. > > So what do y'all think? Would this work for OpenSG and are the core > developers interested in trying things this way for a while? If it > doesn't work we can always change. > > >> More below. >>>> 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. >>>> >> Does Skype have a voice conference feature? That would be neat and might >> make for quicker communication. For chat I prefer gaim/jabber(google-talk). > > Yes, it has the ability to support chats of up to 100 people in the same > room. This could be very useful say for a monthly "core" call or pair > programming (combine skype with gobby and we could have people from 3 > continents programming on the same piece of code :) > > > >>>> 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? >>>> >> I don't think it has to be like this. Currently it feels like everybody >> has too many things that they need acutely to think about/work on >> longer-term things. I can see a reoadmap helping with focusing efforts >> in a more directed way, if the pieces in the roadmap are small enough >> that it makes sense to change direction on some thing so that they >> better align with the general direction. I think the Trac model works >> well for this one. >>>> 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 don't know how much users care about the roadmap, really. I know some >> of you have talked positively about it, but personally I look more at >> the recent activity in a project and the available features before I get >> more interested in trying to contribute. In any case, a roadmap a la >> Trac would make sense. > > But you aren't a tradition user, you are a techie developer. Roadmaps > do make a difference to end users. For example my business customers > would be very interested in seeing that OpenSG has a life and a plan. > >>>> 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. >>>> >> I would love to have something like that. If we all (we being anybody >> developing on OpenSG, myself included) could seriously dedicate some >> amount of time on this and stick to it I think we could make it work. >> Accountability is a problem here as it's a volunteer effort, I think >> that needs to go into people's head much more than anywhere else. > > Agreed. The project is probably always going to slide. But we can at > least track what needs worked on, who is working on it, and what is the > status. Unless the project got some major funding we are not going to > have people working on it full-time. > >> It would also be useful to have people who want to help but don't feel >> confident they have the time and skills/persistence to code the core. >> Documentation and demos are things that always need help. So to help >> those people it would make sense to have tickets for these pieces, too. >> We've been adding some tickets in that direction, but it would make >> sense to have a better structure and much more input/use for that. A >> problem at this time is that I haven't finished the structure for docs >> and example/demo/tutorials builds. I'm trying to get to that, but I'm >> about to go back to New Orleans right now. I hope I can negotiate with >> my fiancee for enough free time over the weekend to finish this. So >> startin gnext week if you want to put your mark on OpenSG, send us am >> example or a demo! ;) > > Seems like you are negotiating a lot with your fiancee. Do you need one > of us to give her a call for you. :) > > I like the idea of having direction for people that want to contribute. > Your ideas sound very good. > > >> Moral: submit tickets, think about a little bit of time that you would >> be willing to dedicate, and find a ticket that you think you can handle. >> And dont' forget to add a comment that you're working on it, or somebody >> else might be faster. ;) >>>> 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. >>>> >> I would be, if it's not a significant burden. With a good and easy to >> use framework it should be ok, IMHO. >> >> What about the others? > > As you may guess, I would do it. Others? > >>>> 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. >> Well, usually the one who answers the most questions in a project is the >> leader. That I think works for OpenSG, too. ;) > > True. I guess I look at it as the leader of an open source project is > the one that sets the roadmap and acts as the gatekeeper to ensure code > quality and usefulness. The thing OpenSG lacks is the roadmap part, > having someone say "These are the things that need done, who wants to do > them?" Using a roadmap (see above) may change this very quickly. > > >>>> 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. >>>> >> That only works when you have a large enough development team that the >> leader group can lean back (figuratively speaking here ;) and lead. >> OpenSG is probably in the awkward intermediate stage where the project >> is big, but there are not enough developers for the core people to get >> out of developing. > > I agree with your point that we aren't large enough to have a pure > leader (and I think a leader like that would be bad anyway). But... > leading the roadmap can be done by people actively developing. > >>>> 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. >> I'm sort of the benevolent dictator in the sense that I seem to have the >> last decision. But to make a decision it has to come to me, and in many >> cases there is one developer that decides to do something and just does >> it. I never get into the picture. Having stuff in Trac might help with that. > > Agreed. And if you wanted to run for full benevolent dictator I would > vote for you. :) > > Sounds like trac, roadmap, and better communication could help the > workflow. I am all for trying to make it happen sooner rather then > later. Any other takers? > > -Allen > >> My $.02 >> >> Dirk >> >> >> >> >> >> ------------------------------------------------------------------------- >> 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 ------------------------------------------------------------------------- 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
