If you want to know anything more about this system, we are having a get together at PyCon tonight at 10pm in Room F (thanks warner!) and then presenting at the RSA Conference at the beginning of March (search the agenda for "tahoe").
That's just a pointless fantasy of Dave Winer's. He has the magical combination technical and social incompetence, that thoroughly poisons anything he is allowed to insinuate himself into.
We have an open source project http://allmydata.org that has been doing this for quite awhile. I'm also involved in the commercial side which does online storage and we've been running a business on a P2P backend (nice low costs) with non-peer clients. We tried a business model with a full peer grid and users were extremely uncomfortable storing "data" from other people on their computers. Possibly the market is better educated now and/or more used to this idea, but it may be a hard sell.
We run a small specialized storage company and the things that seem to matter most are: storage capacity, availability, reliability, transfer rates for both current data usage and new data addition.
40Tb can be handled pretty well by S3 and other storage services and they have pretty good pricing information to model your costs. Note that they don't (yet) provide very specific SLA's for data availability, so keep that in mind when designing your system.
Maintaining your own drives with some sort of redundancy (RAID, automatic copies, etc.) or using something like (bias alert) our open-source project http://allmydata.org which is effectively a software RAID layer both require some IT and systems energy, so this has to be bundled into your operational costs if you choose that route.
Just to emphasize what others have mentioned, it is important to incorporate the new data influx rate into your model. If you are successful, 40Tb this year might turn to 120Tb next year, so make sure that your cashflow model can support the underlying cost of whatever system you choose.
We decided to write our new architecture from scratch as an open source project to support our commercial business offering (online storage and backup). There are several factors to consider, roughly in order of importance (according to me):
* target audience
* marketing advantage or disadvantage
* peer review importance
* publicly enforced project management
* contribution from open-source community
Our target audience is composed of consumers who want a simple product to backup their computers and a more sophisticated audience that wants to design and maintain their own distributed backup service. For the consumers, open-source isn't necessarily a plus or minus (see marketing below) but for the more sophisticated users (enterprise IT folks) open-source is great if they need to make modifications for their special needs.
Similar to above, marketing your project/product/service as open-source may be very attractive to some audiences (enterprise IT, hackers who want their own storage grid), irrelevant to some (consumer PC user), and negative to others (some investors, some potential buyers).
One very strong benefit that we've received is peer review by experts in the field. Because our system must securely and robustly store sensitive information, the more people who read through our design and implementation and comment on it the better. Several design and implementation suggestions have helped us fix or improve our system immensely.
Because our project is open-source the peer pressure placed upon good design, documentation, and code is much higher than in my previous experiences with proprietary software. Though not perfect, it means that our team has worked hard to make the system usable and not pushed off important items that might not be visible to a busy project manager.
Code contribution has not been a major focus of our project, though we have received several very good additions to our project. I believe (but not backed up with data yet) that our particular project does not lend itself to large amounts of people coding on it as it is not (yet) a platform.
I do this already in the Bay Area in California. There are several carpool pickup points in the East Bay (Oakland/Berkeley) that drop off in downtown San Francisco. I either pick up people here or hitch a ride every morning. The advantage is that you can use the carpool lane which saves 10-15min during rush-hour and a $4 toll.
We are using ADP TotalSource for payroll and PEO functions. Though it is nice to have everything in more or less one place, the response time and customer service is extra-medium. By that I mean that most of the time if there is a problem with health care coverage, I end up personally having to call the provider, ADP merely provides a phone number. On the positive side, the prices are reasonable and the variety of plan offerings is good too. They just started up their west coast operations last year.
We looked at Administaff as well and the main reason for going with ADP was a pre-existing relationship via payroll.
I would first determine if your source code really warrants the effort needed to keep it secure from prying eyes. We've evaluated several factors including the source code, the service built leveraging that codebase, the people involved in the execution, and the business plan that mixes everything together. For us, in every scenario we could model the value generated by the code was much higher if it were open-sourced.
For example, because the code is open to all, the developers are motivated to produce much better documentation and testing harnesses, usually before they actually do the code itself - internal costs go down. This pays for itself many times over in time saved during debugging and deployment.
Another example is that we've received a lot of critical peer review of our code which has helped us catch and fix flaws in our security and design - internal costs go down, public perception of security becomes positive.
In my experience and market research, it is nearly always the execution of the business that significantly outweighs any super-secret Python methods I may have thought were cool at 2am :)
