Our youngest brother sent us a link to an article in Slate about a "Google PC", which, one supposes, is where the company is going, what with its recently released spreadsheet, its Writely word processor, and the myriad other features it is offering to anyone who signs up. There was also a story about Microsoft CEO Steve Ballmer's announcement that the company plans to put more software online.

But what caught our attention was a link in the Slate story to YouOS, a web-based operating system developed by four guys who met playing basketball. According to their website, they want to build a system that liberates -- their term -- software from hardware. "An application's code and data reside remotely but are executed and modified locally," the website says. "You can edit a document at home in a text editor and then go to school or work and instantly access the same text editor and document."

YouOS is still in development, so any criticism one might have about what they're doing should be tempered with the awareness that the system's developers have been at it for only about seven months (they don't say whether the fall from playoff contention of the Golden State Warriors was a contributing factor). It is a real, honest-to-gosh functioning web operating system, and it doesn't require anything more than a decent web browser to work.

The entire framework is open source; not only does YouOS encourage the development and "tweaking" of APIs, but even the client interface is open to change. YouOS has even turned the process into a game, with rankings, buddy lists, and the building of a community that, to quote the website, is the operating system.

The system opens a desktop within a browser window (pick one, any one). The default configuration comes with a minibrowser that works (it even picks up the Experts Exchange cookie from your computer); a little rich text editor that includes the ability to export to a PDF file; a shell that lets you manipulate your files and folders; some collaboration tools; and a nice wallpaper that appears to be somewhere along the coast of California. There are also over 100 applications one can use. Don't expect the richness of Excel or WordPerfect quite yet -- most of the applications were developed by others, and some are little more than a window to another online application (like the Google spreadsheet or YouTube).

Loading new applications is simple: just select and install. No keys, no CDs, no serial numbers and no EULAs that resemble the US tax code in complexity. Another very slick attribute to the YouOS system is that (for example) if you're writing a document and close your browser, you can reopen the browser even days later, log back into YouOS, and you're right where you left off.

There are downsides, the main one being the result of getting publicity, and no doubt this article will contribute to it: YouOS can be slower than molasses in January, even on a cable connection; the lag times between opening an application and actually being able to use it can be pretty frustrating. There are some interoperability problems; for example, files saved using the installed text editor don't show up using the file manager, and can disappear, even when opening them from the editor. The PDF files don't save text formatting very well (the file we typed using Arial was saved in Times Roman). There are no doubt tons of others.

But we'd rather not dwell on what doesn't work; we're impressed that YouOS works as well as it does. It is proof that it can be done, and that it doesn't take billions of dollars to do it.

gregoryyoung is the Page Editor for two of Experts Exchange's programming topic areas. He was recently named a Microsoft Most Valuable Professional; this article is reprinted from his blog.

This post is coming up from a recent discussion I had with Rusty Zarse; these thoughts have crossed my mind before but the discussion put them back on the top of the stack in my brain. I have also been writing a lot lately about low level CLR type stuff and I don't want to get shoehorned as a CLR nerd so I also figured it was time for a non-low level post.

Since my first agile experience way back in 1999 (well XP but close enough) I have always leaned towards agile methods in corporate environments. There is, however, one hurdle we must overcome before agile methodologies can gain a wider acceptance. This hurdle is not getting people to accept pair programming, recognizing that writing unit tests and refactoring does in fact lead to better code, or the acceptance of documents having prices associated with them. This idea is not a new idea but a dredging up of an old one (with a bit of a twist) that has never really had a good answer.

Agile methodologies happen to have a fairly large impedance mismatch with the legal contracts associated with a project. Agile methodologies are all about trust, while contracts are all about protection. The very concept of a contract requires heavy documentation as to what each side's responsibilities are in order to fulfill their end of the contract. Can you imagine for a minute going to a builder in a new development around the corner from your house and signing a $300,000 contract for them build you a house without a floor plan or other specifications being included in the contract?

Not surprisingly, when a project is being outsourced companies also like to know up front how much the project will cost so they can accurately detail the financial risk of the project. Since the contracting firm is forced to put forward a fixed price bid the company needs to get a detailed specification in order to put a fixed scope of work into the contract for their own protection.

The problem in dealing with agile methodologies in these situations is not when things go great with beautiful customer relations and a successful product. The issues raise their ugly heads when the project fails; since the contracting company is contracted to work on a moving target, when have they legally met their obligations of the contract? The hiring company could feasibly continue to add functionality way beyond the initial scope of the project.

Martin Fowler has written a bit on this issue which suggests that you should instead be setting goals based upon money and time lines when dealing with fixed bid contracts.

To handle this with a fixed price contract you essentially come up with a plan that says "we have $x to spend and we need a release on 1 Dec. We'll collaborate together to come up with the best set of features to go live with on that date."

There can be no teeth in the contract to insure the hiring company that they will in fact receive a product that works to their specifications; the contracting company cannot in their own best interest allow such teeth to be put in since they are approaching a moving target. Continuing with the house metaphor, can you imagine going to the building company and signing a contract saying they will work on the house for 75 days, they estimate it will take 75 days but they may be off by up to 40-50 per cent. If they happen to not finish your house in the 75 days then you can feel free to pay them more until the house is finished unless of course the builder has someone who will pay them more in which case they will be unavailable due to scheduling conflict. If we take a closer look at Martin's suggestion what the hiring company has done is actually bought a block of time at a fixed price, but there are no teeth in the contract stating that the software will be complete (or that the plumbing will be installed).

This can open the contracting company up to lawsuits that are nearly impossible to fight and will likely end up in arbitration. The contract says that company x will provide company y a payroll system by December 1st on a $500,000 budget. What is the exact definition of a payroll system? The functional requirements of the system have simply been collaborated on since the inception of the project. Since there are no detailed requirement documents being brought together and signed off on the hiring company could easily gain a good legal standing in a claim against the contracting company.

This issue is best shown when dealing with government based RFPs. Can you imagine the political turmoil if a 3 million dollar system was contracted in such a way and at the end of the contract the contracting company refused to continue work because they had received a higher paying contract? A politician can, which is why it will be very hard to sell anything to them without them being able to put real teeth into the contract to protect their and their constituents' (I guess I should have just said their :)) best interest.

Even if you can get a customer to understand why you are not offering a fixed cost, there will always be some less than admirable salesman who convinces them that their company can. A person without a lot of experience in software development will assume it is a better price as your price comes with an obvious unknown amount of risk, and they will more often than not choose the contract from the less than admirable salesman. You don't generally get fired for providing a mediocre solution at cost with a vendor on the line contractually (it is the vendor's problem). You do get fired when you are $100,000 over budget in consulting bills with an incomplete project as it becomes your own mismanagement that is the problem.

I am not a lawyer but I would love to hear some legal thoughts on just how to put teeth into these contracts without providing explicit criteria for completion of the contract. Until I see successfully litigated cases (which there may already be) I am reluctant to even attempt being agile on a fixed price bid.

1. What are your thoughts on the subject?
2. Have you ever been in a fixed price project gone badly where your saving grace was the fact that you did have a full specification document up front that you could reference to show completion and to help side step feature creep?
3. How do we change corporate culture to move away from fixed price contracts?

We travel quite a bit -- a few days here, a week there -- so we've become rather adept at finding free WiFi hot spots: coffee shops, hotels, libraries -- where we can do the things required of us. So we were not terribly surprised to read an article about how loiterers are causing proprietors to rethink their business plans.

That makes sense to us. We did our time in the restaurant business, and the key to making a profit is in turning over tables. There are a fixed number of seats, so if someone dallies too long, you can start losing money pretty quickly unless he's making a lot of trips to the cash register. (We knew one manager who would crank up the air conditioning during the bar run on Friday and Saturday nights. The service staff was too busy to notice, but the customers did as soon as the excessive alcohol started to wear off.)

But what really bothers us about the people who tie up a table in a local cafe for five hours while buying one double mocha is that it is downright rude -- and it seems to be symptomatic of a larger ill that is plaguing our wired (and unwired) world. It's the plague of bad manners. It never crosses that guy's mind that other people want to partake of the coffee shop's wares; he wants to finish his proposal or reply to two more emails.

Starbucks doesn't give away WiFi access for free; like it or not, the company offers a pleasant atmosphere, newspapers, decent food and coffee, fairly consistent service -- and very few seats, so even if you want to sit, they're going to make sure you pay. They want you in and out: "thank-you-very-much-can-I-help-the-next-person-in-line" is a single, multi-syllabic word. But it's not Starbucks' responsiblity to teach people that it is mildly antisocial when they spend six hours in a seat for $1.95.

We can generally live with not being able to log in for a couple of hours, or even days; we understand that the sun will probably come up tomorrow if we don't read our email today. Four decades of dealing with deadlines has taught us one thing: they're almost always marginally flexible. We figure that if it's not that important that planes always take off and land exactly on time, then very little else is that critical either.

And what of those cafes that are now turning off the wireless routers when they're busy? Aren't they being just as rude to their customers who have, after all, bought their wares? Well, yes, they are -- and it's not because they want to be fair to the other people who want to sit and watch the world go by. It's because it affects the bottom line. That is putting their own interests above the needs of their customers -- and that's rude too.

We would love to think there's a solution to all of this -- some kind of neat, tidy little rule that everyone would follow -- that would make the world a little less tense place. But we're not going to hold our breath.

Believe it or not, this isn't the only newsletter I subscribe to. One of them had a couple of interesting items that have to do with your email, and with protecting yourself, that I thought I'd pass along.

The first had to do with protecting your home wireless network. About a year ago, stone5150 wrote about WEP (Wired Equivalent Privacy), and that got responses from two members who suggested upgrading to WAP (WiFi Protected Access), which is more secure than WEP was. For most people, that means checking the website of your router's manufacturer for a firmware upgrade, but for those of you who have older routers, it might require an upgrade.

The other item had to do with tracking down the people who send you either junk or inappropriate emails. You can almost always find out where the email came from by looking at the source or "properties" of the email. In Outlook Express, you can check it from the list by highlighting the email, right-clicking, and selecting Properties, and then looking at the detail. Near the top of the mail, you'll normally see several sets of data that begin with "Received: from". The top one is the server that sent it to you -- your ISP usually. The last one is the server that originally mailed it.

Don't believe the name that's shown. Email addresses are often spoofed, so while it might tell you the email address of the person who sent it, since the email is junk, it probably doesn't. However, it will give you an IP address. You can use that to look up who owns it and where it came from, starting with this locator tool. You can then do a WhoIs search to find out who is responsible for the domain.

One warning though: I wouldn't spend too much time on it. For one thing, a lot of the junk mail we get comes from one of two sources -- it's either a spammer who isn't interested in taking your name off the list, or a zombie computer somewhere, run by a bunch of crooks. Either way, you'll spend a lot of time without a lot of results. If your time is at all valuable, you're better off getting a good spam filter.