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
