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. ;)
> 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?
>> 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.
>> 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! ;).
>> 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).
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).
>> 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.
>> 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.
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! ;)
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?
>> 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. ;)
>> 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.
>> 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.
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
