Hi all,
after struggling a little bit, here we go with my $.02.
First the central question, what is OpenSG to me ;-)
Definitely something to have fun with, something that gets me out of
engineering hell ;-), something that occupies my mind with interesting
questions, something that is a little bit closer to science than what I
do most of my off-the-shelf working hours. So turning around and do
engineering work on OpenSG is not the easiest thing to do for me ;-).
But also something that provides rewards if other people like and
use it ;-). About the world domination issue I haven't thought to
much so far ;-)
and now the rest
'Executive Summary'
-------------------
Overall it seems to boil down to 4 main items
- Marketing
- Documentation
- Usability (e.g install / build / extend from a users perspective)
- Development organization
with the borders being kind of grey. Or even shorter,
'Communication Problems'
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.
That would, for the time being my one and only starting point, well more
for the next week or two than months.
Once we have a working communication structure we feel comfortable with
in place we can go on and address all the technical issues. We have done
it the other way around so many times that I wonder why we should succeed
this time if we repeat our usual pattern, so maybe it is time for a
change.
And now on to some some random thoughts on the different items.
Warning some points use a rather sharp formulation so use the
;-) as a hint where this might be the case.
- Marketing
For marketing, honestly this is really beyond me and I really don't want
to get even close to it ;-).
Which however does not mean that I will not support it from a technical
perspective, even as far as compromising on design issues where needed.
I just do not see that I will have time to discuss strategies for world
domination ;-) and things surrounding this little goal ;-)
(e.g webpages).
- Documentation
On to documentation, as said we are really worse than bad ;-).
One item that might help in general is getting rid of the split between
tests and examples. Having tests is mainly just an easy to use excuse
for us not to include the proper documentation, because you know 'these
are only test never intended to be read by anyone else'. Unfortunately
more than often they are the only way to figure out what is possible.
And you can only build them if you build OpenSG yourself.
Having an accompanying wiki page for each tutorial might also be a good
starting point to get the wiki part going.
Another not to underestimate problem is IMHO that some of us use
software layers on top of OpenSG. In those cases you (at least I)
often end up generating test cases from your closed tool chain instead
of using OpenSG directly. The only solution I had so far is dumping the
tree to .osg clean it a little bit and provide them as a reference but
I'm still not sure if this is a workable solution. Maybe there is even
a way to take the .osg dump to create working .cpp tutorials.
But the major problem I see is the imperative, at least for me, to spend
time on documentation and especially where to get the time from. If
anybody has a good idea how to do this I'm all open to suggestions,
except to those that involve physical violence ;-).
And IIRC the documentation build times where even worse than the C++
build times, which makes putting things in there on the run quite
painful. That might be something we should workout sooner than
later. One thought that popped up was putting the general
documentation (e.g System.dox) into the wiki to avoid the doc
building pains. The two, hopefully solvable, remaining problems
would be, how to get them back into the doxygen created documentation
(if wanted) and how to reference the class documentation from there.
Not having thought about it in detail I'm still optimistic that some
script and wiki template magic will do the trick.
We also should find a way to have some usable issue/bug trackers. I
don't know why the ones sourceforge provides did not catch with OpenSG.
A last point in this section, user space documentation, e.g. FAQs,
HowTos. For me this is one of the entry level points of community
contribution.
Figured out something, put it into a small FAQ/HowTo style comment and
send it to us (or put it into the hopefully soon to be wiki ;-)), have
a small testProgram, even better, include it. For me writing this kind
of documentation is incredible hard.
--Usability (e.g install / build / extend from a users perspective)
Some people already work on new, improved build frameworks so
I will not comment on this area to much.
Only from the comments I've seen so far what we should look into is not
only providing native workspaces for at least Visual Studio but also
make their creation independent of the shell based build systems.
Currently you have to have to run configure in a cygwin environment to
run the tools to update the projects files. I haven't seen the use of
scons from within visual studio so I can not say if this is really a
solution or not. I haven't looked into it, but Maya for example
is able to add a customized new project dialog to visual studio,
something which for sure would make it easier to start windows projects,
if somebody has some hints how to do this, let me know.
1.x is horrible to extend. I hope we cleaned up a lot of the magic for
2.x (sorry, no more recursive templates ;-)). One thing we should
definitely add is a tool to create custom fields. With the change to
boost functors a lot of the pain adding new node cores should be
gone too. It should be one of the factors we measure the 2.x design
against.
With the removal of the begin/end calls 2.x hopefully should be
a little bit more user friendly than 1.x was, though the Node/NodeCore
split we keep. The need of customized pointers is under investigation,
so we might get rid of those for 2.x.
Hmm anything else, right, if you have something you really really hate
about OpenSG 1.x let us know so we might have a chance to improve the
situation for 2.x.
- Development organization
I'm still sorting through this one to find something that does not
fall into the communication category. One thought would be to have
kind of 'subsystem maintainers'. But subsystem maintainer more in the
sense of a fixed contact person for certain issues like loaders,
rendering backend, cluster, language bindings, ... than strict code
maintainer. More somebody who looks after certain things in general.
Currently the first problem somebody interested in contributing has to
solve is to pick the right person in the fuzzy cloud of involved
individuals doing OpenSG. And more than once I heard, 'oh I talked to
xyz about abc and it somehow never got anywhere, didn't you know'.
Or maybe it is just a way to structure development discussions along
subsystems. Which raises another thought. Probably we should have
something like discussion forums for different development issues.
Flooding a single or two mailings lists seem to be not very productive,
but maybe this is just my poor mailbox organisation.
enough for now.
gerrit
--
It's Emergent[*], you see.
[*] [adj] A word favored by computer nerds; mandatory for DARPA research
applications; on recent evidence, a synonym for 'doomed'.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
