Revision as of 15:20, 20 June 2008 by User (talk | contribs)
Jump to navigationJump to search

Let's keep this as a running list of things between us

Brad talks to Vlada. Keith commits to 1 year @ 100k or $50 / hour. 2 years might very well be possible, but I will know a lot more in 9 months.

Rightfully so, my wife has concerns of job security, medical coverage and the likes. I would like to see how we can turn this into a long-term effort without depending on you covering me forever.

Brad hears back on Industrial Nano.

Brad considers part time work on this, and how to balance this versus work on the book and his other things. How passionate do you feel Maybe you break your work up into blocks: Wiki / blog, book, sensor work, industrial nano / Orlando / etc. This needs to be thought about. Doing this at the same time as the book is good because it gives you feedback that gives you enthusiasm to work on the book. And it could even be a research vehicle for your book!

All of these at once will be too much to do any well. IN and Space Orlando are simmering along - I am waiting for others. If either happens then this effort is the benficiary because they are all closely related and IN or SO will generate revenue to pay me permanently. The book is good for continued revenue and general public outreach but the online Wiki has more value in the technical development and has its own outreach potential to a different audience.

Brad thinks about how the nanotube portion of this wiki could dovetail with his nano company. Maybe it could be a research vehicle and a source of customers for his nanotube company!

Yes, these two would feed each other nicely.

Brad thinks about what list of things should be in the wiki to ensure it reaches critical mass? How could and people working on the space elevator games help contribute to this?

Brad reads Keith's book and takes notes.

On page 29. Editing comments so far.

Brad finds some available URLs that he likes and puts them here:,, etc.

Just thoughts... Available:,, (Space Elevator Development Project),,,,,

Brad thinks about whether there are some servers he'd like to consolidate.

Keith purchases domain, sets up server and creates wiki. (If the old wiki is available on the Internet, I can do a port of all the data over.)

Brad dumps all the simulations, spreadsheets etc he has scattered around into the wiki (even proprietary formats are fine for a start. I can help convert them.) Don't put the actual book text which you will want to update and sell. The wiki will be live with live numbers and live simulations, whereas the book will be a timeless, readable, high-level, linear snapshot.

Keith prefers to pay for wiki and help with wiki. Keith has ideas about the book and wants to read a new version, and thinks the book is important and can be a source of income and would be interested in helping with that, but wants to attempt to build a community that achieves critical mass and is doing real science. We are too small to afford to do fake things.

Brad thinks about the Open Dynamic Engine physics engine (C# wrappers are ODE.Net which are much better to program in) and other simulation tasks. The Internet is filled with cool technology and we need to be on the lookout for it. One of the biggest tasks for my other project is to find all the best codebases for what we want. There are sometimes two or more free codebases. One might be a Ford, and the other a Ferrari. Both are free, so we'd be stupid not to make the right choice. Of course, figuring out which codebase is better is not a totally trivial task. We are too small to afford to do everything ourselves. How would one build a Boeing airplane as an open distributed effort? We need to build a database of component parts using as many things we find on the Internet as possible. This is an example of the archaeology process that Brad should be doing. Keith can help with this and also provide programmers, etc. Building a simulation of something as increasingly realistic as a Boeing airplane ought to be our task. If some people want to build scale models, they could just chuck a bunch of the complexity. It is easy to throw away complexity. There is no reason to build virtual toys. A software simulation is as good as you want it to be.

Brad installs OpenOffice 3.0 beta (it is stable) for mac:

Finished items or items handled elsewhere