I've been following this discussion with some interest. I feel it's moving in the right direction. There is one thing I wonder/worry about. I've created a couple of interactive websites from time to time. It has been sometime since I've done so, so I'm way out of date with the latest tools and techniques. I created these sites with relatively simple cgi scripts written in perl. These two sites were created about 15 years ago and have worked without problem for all that time. I've had to make a few tweaks every couple of years to keep things humming. So although not as "slick" as many current options, they have low maintainence and provide all the functionality I require. This is bottom line for me. In the intervening time, there have been a myriad of tools created to do this job "better". Also the number of libraries available as perl scripts is much, much larger. I've experimented with other method such as FrontPage, ASP, very occasionally to see if I was missing something. The only thing that I think I might use if I were to do this again is javascript. I am very skeptical of "fancy tools". They tend to make things "simpler" by hiding how things work. The tools look great when you demo them but when you actually try to use them you find yourself trying to "trick" the tool into doing what you want. Eventually users catch on to this and then become customers for the next "solution". It becomes an endless cycle of adding "cool" features then spending a lot of time to keep them working. This same problem infects all of modern life. The VCR mentality has spread like a cancer. The current concrete example is the boost.org website which uses a few of these "fancy" tools and has become hard to extend in the way we want. Soooooo ..... Just one man's opinion that the focus on tools is overdone. I would like to see a discussion about the structure of a "new" website before getting into the "tools". Of course I said most of what I wanted to say about this subject in our discussion regarding this subject at BoostCon. At that point, I sketched out something that could be done without amending www.boost.org. But now that this cat is out of the bag, I'll offer my two cents. www.boost.org pages about boost ( basically static pages) history practices procedures .... library index Review/accepted libraries Alphabetical list links to library pages By subject links to library pages Submitted/accepted candidate libraries Alphabetical list links to library pages By subject links to library pages Each library page - similar to what I presented as an example - see http://www.rrsd.com/software_development/boost/BoostCon2010/library_status.h... This page would be mostly links to deployment. issue tracking, forums/list. That is, the implemention of each of these aspects would be left to the developer. Some libraries need only the simplest of discussions - e.g. state_saver, Others need the full blown Track or similar system. The lack of a "unified" system will be found to be off putting to some - but this methods lets Boost evolve as necessary. Robert Ramey