Re: [Opensg-users] Is OpenSG going down the drain?

[Dominik R. <dom...@gm...>]

Hi.

Am 13.01.2010 09:43, schrieb Dirk Reiners:
> thanks for being open. I'm sure there is much you always wanted to know about
> OpenSG (but were too afraid to ask ;).
>    

Very afraid - considering that there are many germans in the core dev 
team, I always fear that you'll beat me up for posting on the list... ;)

> (...)
>> * The last official release 1.8 in 2007. Tons of features have been
>> added since then but nobody knows about them. OpenSG 2 will be released
>> "really soon" for at least 2 years now. The well known other scene graph
>> with the very similar name had 5 releases - in 2009 only. To quote Joel
>> Spolsky here: "Real artists ship!"
>>      
> That's the first time someone quotes Spolsky on me (and a recent one at that).
>    

I have to admit that it was pretty unfair, as, looking at all the code, 
you all definitely qualify as artists without shipping, too. :)

> (...)
>> Long story short, it's the same old rule: What good is an awesome
>> product if there's nobody out there who buys/uses it?
>>
>> Please keep in mind that there are not only academic users out there who
>> write what I usually call "fire and forget" research code but also
>> companies (like ours) that chose OpenSG as a base for their commercial
>> development. Getting employees into OpenSG is a major investment (mainly
>> because of the still pretty poor documentation).
>>      
> Sorry to hear that. I thought the Starter Guide is a pretty decent start,
> although admittedly it does not go very deep. What's the main problem that you see?
>    

Unfortunately, I don't have a recent version of the starter guide here, 
but...

... I tend not to have (and if so not to use) documentation on my local 
machine but to look it up in the internet - especially since building 
the doxygen part of takes more time than building OpenSG itself. 
Unfortunately, the doxygen documentation on the trac site was nearly 
always out of date.
... as you already said, the starter guide does not go very deep.

>> (...)
>>      
> (...)
>
> OpenSG is not dead at all, on the contrary, there is a lot of pretty cool stuff
> going on (Deferred Shading is only the beginning, there is quite a lot more in
> the wings). But you are right, unless you happen to stumble upon this mailing
> list, you will not know.
>    

True, absolutely. Updating regularly and scrolling through the commit 
logs, I know that it's not dead - but searching for OpenSG on the web, 
it smells like it.

> So now, what do we do about it (emphasis on WE, meaning everybody reading this)?
>
>
> Basic things:
>
> If you think OpenSG is interesting and important, go to the SF page
> (http://sourceforge.net/projects/opensg/) and recommend it. Right now. Takes 20
> seconds.
>    

Been there, did that.

> Web sites: I already closed down the (unused) Trac and SVN on SourceForge. We
> still have the 1.8 CVS on there, which I would like to shut down, but I know
> that would cost me my head, so we'll leave that until everybody's migrated. I'm
> in the process of migrating opensg.vrsource.org to a new site
> (external.lite3d.com/opensg). It's not working quite yet (Trac plugins can be
> pretty darn stubborn), but I'm optimistic to get it to a usable point in the
> next few days. Once that's done we can redirect www.opensg.org there and the web
> should be back.
>    

I think it's perfectly fine to keep the 1.8 CVS, however, it should be 
made clear that this is a legacy version and that new users are supposed 
to use 2.0. Removing the stone old daily builds from SF also shouldn't 
hurt that many people.

> Release: That's a bigger problem. I've been reluctant to do a 2.0 release as it
> is a one-time chance to break backwards compatibility, and I really, really
> wanted to get it right. Unfortunately it's been taking so long that other
> commitments, both private and professional, have eaten so deep into my schedule
> that I don't have enough time to really work on it any more.
Sigh, I know what you mean (regarding the other commitments). However, 
when you're talking about backwards compatibility, are you talking about 
1.8 to 2.0? Do you really think that this is a show stopper? I don't 
think that there are many people out there that expect a major version 
change to be backwards compatible (I, for one, don't).
> Carsten took up a
> lot of my slack, but he is more and more needed on the project that actually
> pays for him that there is only so much he can do. Gerrit's situation is
> similar. We're all using OpenSG in our projects, but the time to do the project
> management part that goes beyond the code that we need for ourselves is
> suffering. To keep OpenSG growing we will need some help from the community.
>    

I think we're in a similar situation here - I spent nearly all of the 
last 15 months in writing testing and evaluation software as a 
contractor for a big corporation with 3 letters, as they tend to pay 
better than opensg.org. :)

However, I guess the community is willing to help, but it needs some 
guidance. I doubt that it will work to just wait until someone moves. A 
short mail to the user list with subject: "Action needed: Website" 
asking for help to set up / maintain / design the website works way 
better than waiting for users to take action by themselves.

> Are we ready to release yet? I don't know. We've come a long way, and many
> things have changed massively and several times over the last two years. I think
> the fundamentals are pretty good right now, so that I'm not feeling too bad
> about it. Which brings us to the next point:
>    

That's what I think.

> Installers. We switched to cmake for the build system (after a long and painful
> scons stint). As a consequence, all the old scripts that we had for 1 don't
> really work any more. That is not as bad as it may sound, cmake does have a lot
> better support for the things we're interested in than make, but it doesn't work
> automatically, and we don't have enough experience to just do it real quick.
> Some help here would really be helpful (see below).
>    

Well, at least for Windows I can take care of that (see my reply to 
Marcus). Putting together some .deb for Ubuntu packages also shouldn't 
be a big deal (although I'm lacking some experience in that regard), at 
least as long we don't insist on getting them into the official Ubuntu / 
debian whatever distributions. I also think that having small helpers 
like Visual Studio project templates, projects / solutions for the 
tutorials etc. would make it easier for people to get on board. Although 
I hate to admit it: I fear that getting new users works best by 
providing an easy starting point on Windows.

> Dailybuilds: Due to see above the old scripts don't work any more. Again, CMake
> helps with that. I will set up a CDash server to complement the OpenSG Trac.
> That will give us a good environment to manage different automatic builds. I
> have not been able to figure out how to use CDash to do dailybuild releases like
> we used to have (see below).
>
> Documentation: The crux for each Open Source project, OpenSG being a good
> example.

After being "in the trenches" for a while now: It's not only a problem 
with open source projects. :(

> I was hoping that Trac would make it easier to get community
> involvement, but that hasn't quite worked out.

True. But it's maybe the other side of the same coin: Setting up an 
"empty" wiki and waiting for the community to fill it is likely to fail. 
Having an outline set up by the core devs (FAQ: Questions only, Answers 
only in keywords, Tutorials, short table of contents and some keywords 
for every section only) would make it easier to fill it.

> We do have the Starter Guide on
> Trac (1.8 and 2.0), which was supposed to be a kick start in getting proficient
> with OpenSG. I know it's not very deep, but we were hoping to get some
> user-contributed documentation here, which has not worked out very well at all.
> The HowDoI's worked a little better, we at least got a few comments, but that
> dried up quickly, too.

Yes, I shamefully admit. On the trac site, there's another problem: It's 
pretty unclear what's referring to 1.x and 2.x. Maybe a dedicated 1.x 
section collecting the old stuff would help. But you're right, we, the 
users, have to do more in that regard.

> I know writing documentation is the least fun part of
> everybody's work (been there, many times), but that's also why it is hard for us
> to do it alone. So if you're new to OpenSG and just worked your way to
> understanding some issue, spend the time to write about it on the Wiki. Even
> something short can be useful.
>    

Yes. I think that sometimes just copy/pasting insightful questions and 
answer from the mailing list and reformating them a bit would do the 
trick already.

> Community: I have to admit that I'm a little disappointed with the community
> overall. It's not a surprise that there is only a few people that really
> actively contribute. I obviously do understand that OpenSG is far from being
> easy to understand. We've done some things in 2 to hopefully make it easier to
> use, and we do have examples on how to extend things, but we have gotten
> surprisingly little contributions. Is that because nobody does extend it? Or are
> you just sitting on a ton of cool code? :)
>    

Well, extending requires usually a very good understanding of all the 
ins and outs that probably not enogh people have. But I guess that also 
examples must be advertised, either on the trac front page or on the 
mailing list. In fact, there is an (orphaned) mailing list 
opensg-announce that might be a place for that. Or, as an alternative, 
just get rid of these unused mailing lists 
(https://sourceforge.net/mailarchive/forum.php?forum_name=opensg-announce, 
announce had the last post in 2005!) and post them with a explicit 
subject on the users list.

> But even for very simple things like my occasional 'What are you doing with
> OpenSG?' polls we get almost no responses at all.

There was a poll? :) We all do lots of cool stuff - a reminder from time 
to time on the list to upload pretty pictures and project descriptions 
to  trac would probably cause more peoply to do it. We will, as soon as 
the website is back (Bastian, do you read? ;) )

> We're happy to help wherever
> we can, and I think our (i.e. Carsten's) responsiveness on the mailing list is
> better than any other project I've seen,
True. IMHO that's the No. 1 argument for using OpenSG and be sure that 
all users highly appreciate that.

> but only seeing the community from the
> side that has problems is a pretty lop-sided view (and not a pretty one). We
> would like to see the other side, too, the side that is happy jumping up and
> down because something new and cool is working now. We see almost none of that,
> and it's not exactly a great motivating factor for spending more time doing
> things that don't benefit ourselves very much (like writing documentation)
> rather than spending time with our families (yes, we do have those ;).
>    

I don't - bring it on.

> Community Call:
>
> - CPack. If anybody knows CPack enough to set it up, please take a look at our
> CMake system and see if you can add CPack support. Our CMake is not trivial, due
> to the many libraries and dependencies and example programs, and we definitely
> need support for Linux, Windows and OSX, so a quick and dirty hack won't cut it.
>    

There's always the solution one wants - and the one that "works". 
Setting up an advanced installer project with a ready made build or a 
debian/ subdirectory for creation of .deb packages is easy. Mastering 
CMake, CPack, CDash etc. is not. IMHO, the result is more important 
here, and the result is a directory on a web server somewhere where you 
can download ready to install packages. How they were created is nothing 
an ordinary user cares about. If anybody is able and willing to set this 
up in a better way in the long run shuoldn't make a difference for the 
user, as the result is the same.

> - Dailybuilds. CDash is a start, but we need people to provide build servers for
> the different platforms. More importantly we need somebody with experience to
> help us figure out how to do dailybuild releases in the CDash context.
>    

What do you need? We got lots of machines (Win, Ubuntu, Mac) in our 
company and let them running over night to generate builds isn't 
something that hurts. However, I never worked with CDash before and also 
my CMake experience is limited to calling the gui, adjusting variables 
to my needs and pressing the generate button.

> - Documentation: if you have something to add the to the starter guide, or if
> you can write an example program that shows an aspect of OpenSG that is not
> covered by an existing example, send it to us.
>
> - Advertisement: The Gallery is pretty nice, but not much is happening on it. If
> you have some new, cool pictures, put them up (once it's up again).
>    

Well, at least on source forge, it already looks way better: 85% of 8 
users recommend this project. ;)

> We'll be happy to coordinate things, so if there are things that you want to
> contribute, be it time or code or data, let us know and we'll see how we can
> make best use of it.
>    

To sum it up: You, the project leaders should do, what every project 
leader should do every once in a while: Remind us (the user community) 
that this is no one way street and that we're needed, ideally by 
defining tasks that must be done. Although we all should know this by 
ourselves, it might help to get reminded here and then.

> I'm sure I'm forgetting a lot of things (it's a little late right now), but I'm
> hoping this can kick off some new energy.
>    

Pretty sure about that.

Thanks and yours,
Dominik