This was actually a feature of Facebook for a while, at least when I joined up. The number one driver for me to create an account on facebook was that I already had a sort of ghost account created by the people I knew. Even though I didn't have an account, people could still tag me in photos (prompting an email), view collections of photos that I'd been tagged in, and a few other basic functions. I joined solely so that I could change my privacy settings.

Gotcha -- thanks for that.
However, that still has a workflow where you edit my file directly, and diffs are tracked by revisions. Is there anyway to make it so that I have to accept/reject changes, or where changes are managed on a change-by-change basis?

As for passing copies of files around, I think it's a fine workaround to put a doc on a file share, in sharepoint, or in source control. Google Docs is actually way better for simultaneous collaboration though, I have to agree with that.

"Usually she agrees, but not always, and she can always see exactly what I did and easily revert what she doesn't like."

How?!
I've started using it a ton for collaboration, but I haven't been able to find a reasonable replacement for Track Changes that you'd find in Word.
Sure, I can comment, or I can just change the text. But, if I want to make changes to the text and have someone be able to see what was changed and accept/reject, I can't seem to do that.

I think Microsoft's strategy is to generate revenue by accepting licensing payments from android manufacturers. This is good for their bottom line as they are making steady income from other people.

Apple's strategy, I think, is to damage their competitors. By keeping android in court, they are hurting sales numbers directly (samsung products being banned for sale, even for just a few months), or indirectly (third party developers question whether android is the right platform; manufacturers reducing their focus on android phones).

They aren't making any money directly from their legal action, but if you look at the whole picture, I'll bet they are doing at least as well as Microsoft. The iPhone still has a hefty market share - which is important for Apple because they make the bulk of their iPhone related money on the iTunes store commissions. If they took licensing payments instead, they would get some money from the manufacturers, but potentially lose their cut on movies, music, apps, etc.

Given the restrictions that you have (keep doing what you're doing, but more advanced) then I would suggest one of two things.

[1] Change to a completely new set of problems. If you've been working in business software, change to games. In this way you will still be doing dev, but the kinds of problems that you are trying to solve will be completely different, which will lead to new challenges.

[2] Try changing up the 'how' of what you're doing. For example, look for a team that's using scrum methodology, or test-driven-development. Alternately, new tools, programming languages, platforms (Mostly focussing on windows? Go mac/mobile/unix/web.). Even just somewhere with a vastly different release cycle could be interesting - by last employer measured their dev cycles in years; my current employer in weeks. If you put the focus on the skills, instead of the work, it can be really rewarding. See Software Craftsman movement for related inspiration in this direction.

[3] Move. I'm on my third country now, and I can tell you that doing the same thing in a different country totally changes the game. French engineers do not think the same way as Canadian engineers. So much of our work is about problem solving, and being able to transform real world problems into software. It's been very cool to working through a problem with someone with a totally different world view.

To use an analogy: You are a great French chef; you've worked in a wide range of sit down restaurants from very small to very large. And you've always felt successful, but you now feel you're only option is to start your own business. I'm recommending that you [1] go work at a japanese restaurant, [2] try a catering company or 'fast food', or [3] try working in Vietnam.

Have you considered hiring a Technical Writer on contract?
From the work you describe, someone with the right experience should be able to pull all of that together for you in about a month -- maybe a bit longer to make sure that it's usable for you in the long term. Writers spend a lot their time summarizing, re-organizing, and pulling together disjointed pieces of information. I'd consider hiring someone to get you running, and then having them show you a few things for how to keep the wheels greased in the long term.

It'll cost a bit extra, but it's likely to get done faster than if you DIY, and you won't have to take as much time off from your existing IT duties.

There was a similar article from Bruce Perens a few years back: http://news.slashdot.org/story/09/02/16/1633200/How-Many-Open-Source-Licenses-Do-You-Need

He describes his reasons differently, but arrives at the same conclusions. For those of you worried about the missing option of the BSD license, he does talk about this a little bit. But only a little bit -- it's quite a short article. Worth a read for an alternate take of the same point of view.

That Yahoo article was a nice summary. Thanks for the link.

I can tell you what happened, at least from the people I know in doc and training.
You mostly got it right, btw.

Documentation used to be a big investment area.
Then training came along. Training made money; Documentation cost money.
Companies started by de-investing in doc, and investing heavily in training departments.
After a while, organizations would start to ask their doc teams to intentionally include less information so that customers would be 'encouraged' to buy training.

But, there was a problem. Where did the training teams get their information from?
Documentation.

Documentation fills the role of a primary researcher for the training departments. They know what's going into the product, how it is supposed to work, and what it actually does as soon as the product is released. Training teams follow a several month lag, as they need to train what's installed on the customers site, not what's in development. Without the source material coming from Doc, it's a lot harder for trainers to pull together great content. They now have to do both the primary and secondary research, but with the added difficulty that the developers are now working on the *next* iteration, and aren't really that interested in talking about the last release.