I rather like the idea of community donated white papers, with two "pro's" editing and compiling them. It seems this would be "quick", and bring together a wide range of experiences.
I'd be happy to do the chapter "OSG for Dummies"... I'll throw in a bonus section on mailing list etiquette ;-) Richard A man who is silent appears wise... The fool who speaks removes all doubt. On Dec 19, 2007, at 10:46 AM, Paul Martz wrote: > Thanks for the enjoyable discussion. Bob and I will meet in about 2 > weeks > and future documentation plans will be a topic of discussion. > > Some random thoughts follow. > > Free documentation... I charge for documentation I develop, just > like I > charge for software I develop. I don't think this is unreasonable. > If you > sincerely believe that OSG documentation should be free, contract > with Bob > and I and pay us to write it. Then it's yours, and you can give it > away > free, just like CGSD/Andes did with the Quick Start Guide. > > For those of you wishing there was more documentation available, rest > assured Bob and I do not intend to stop where we are. However, know > that OSG > is large, and documenting all of it will take time. I think we've > made good > progress so far. > > Without contracts to develop documentation, Bob and I squeeze in > documentation development around our (better paying) contractual > software > development obligations. This environment prohibits any large-scale > dedicated documentation projects, and means that documentation will > have to > come out in small bits and pieces. > > The idea of writing separate whitepapers on various topics is quite > appealing. I see two different approaches here: > > 1) Bob and I write them all, release them as they are completed, and > after > we reach some critical mass, we assemble them into the "OSG > Programming > Guide" and release that as a book. > > 2) Members of the OSG community all write articles on various > aspects of OSG > and submit them to Bob and I. We edit and assemble them and release > the "OSG > Gems" book. > > So I really see those as two different projects. Both seem doable, > but the > "Gems" book implicitly assumes community contribution, and past > experience > indicates the odds for this happening are quite small. (To be fair, > having > Bob and I write whitepapers implicitly assumes we'll have time to do > it -- I > think we will, but the papers might not appear as fast as we'd all > like.) > > However, I like the idea of a community-written "OSG Gems" book, and > I don't > want to underestimate the community's willingness to contribute. So, > I'll > give this some thought, look into other Gems-style books' business > models, > and see if I can find a way to make this work (time-wise, as an > editor). > Initial thought: rather than "here's how to use some feature in OSG" > type of > articles, it might be better to have "here's how I did this really > cool > thing using OSG" or "here's how my company is using OSG", if you > know what I > mean. I think this is more in line with other Gems books I've read. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > 303 859 9466 > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
