A decent client-server model of office could definitely take it down. Sharepoint is ridiculously heavy for what's needed. It has too many features and doesn't present the key ones easily. Document production is conceptually simple in people's minds. Even I have found it awkward to adjust to appropriate use of sharepoint (and I still hate it).
Office users need something that places a genuinely excellent wordprocessing frontend as a frontend to a repository. Within this you'd have to facilitate good search, allow for data flexibility. Generally at the moment you need to be able to produce views of word processed documents as PDF, single-page HTML, multi-page HTML (oh - there's a style need I missed in my other comment), XML and IP-based API. The frontend needs to effortlessly handle massive documents without compromising the frontend and it needs to be possible to edit all of a document at once, or sectors of it. All this can be coordinated with a smart approach to use of the existing filesystem model.
The storage format needs to be textual to facilitate source-control and version diffing.
With the office space it's important to separate the things that users care about from what they don't. They care about the lovely frontend and a small subset of features. They don't really care if it backs on to a powerful custom engine. They care about features in the big-picture sense, but would not necessarily demand that they be offered in the frontend if they could be better achieved through another mechinism. Fortunately Microsoft have provided stunning tools for third party developers who want to extend Word and Excel and there are masses of good docs around on it.
Office can be done, but the people doing it need to look at the problem itself rather than trying to beat Microsoft at their own game by producing yet another crap monolithic arbitrary-format grinder. Think wiki but with a fantastic frontend (and by that I don't mean some horrid javascript GUI in a browser that is unresponsive and chooses to sometimes lose your data).
Office users need something that places a genuinely excellent wordprocessing frontend as a frontend to a repository. Within this you'd have to facilitate good search, allow for data flexibility. Generally at the moment you need to be able to produce views of word processed documents as PDF, single-page HTML, multi-page HTML (oh - there's a style need I missed in my other comment), XML and IP-based API. The frontend needs to effortlessly handle massive documents without compromising the frontend and it needs to be possible to edit all of a document at once, or sectors of it. All this can be coordinated with a smart approach to use of the existing filesystem model.
The storage format needs to be textual to facilitate source-control and version diffing.
With the office space it's important to separate the things that users care about from what they don't. They care about the lovely frontend and a small subset of features. They don't really care if it backs on to a powerful custom engine. They care about features in the big-picture sense, but would not necessarily demand that they be offered in the frontend if they could be better achieved through another mechinism. Fortunately Microsoft have provided stunning tools for third party developers who want to extend Word and Excel and there are masses of good docs around on it.
Office can be done, but the people doing it need to look at the problem itself rather than trying to beat Microsoft at their own game by producing yet another crap monolithic arbitrary-format grinder. Think wiki but with a fantastic frontend (and by that I don't mean some horrid javascript GUI in a browser that is unresponsive and chooses to sometimes lose your data).