The Man Who Would Change Microsoft

Ray Ozzie gives a very nice interview to Wharton. Some excerpts:

Accomplishing this feat won't be easy, in part because Microsoft is facing challenges on multiple fronts -- technical, business and cultural. New cross-platform technologies threaten to establish a new layer of abstraction that could reduce the importance of the operating system as a software development platform.

The first task is to bridge the different groups [within Microsoft]. I might see something going on within one group that another group might be able to take advantage of that [might not be visible] from their vantage point within a division. So, in essence, it's an architect one level up.

It's essential that [Microsoft] continue to understand its customer requirements and to advance those products in a way that isn't just at the margin. For example, the Office business [is really] the "productivity" business. So, they have an obligation to continue innovating around what people do in managing documents, meetings, projects and so on.

And then on the Windows side, there is continued opportunity because of how hardware is changing. Disks continue to get bigger, there are [features] like flash memory that might fundamentally impact the performance of laptops and PCs, bandwidth continues to increase, screens continue to be reshaped, natural input such as cameras and voice continue to be important. Everyone finds battery life to be a challenge, particularly when you fly five or six hours and you're trying to work. There's a lot of innovation that can happen within the OS, working cooperatively with the hardware and driver vendors, to extend battery life.

In each solution within our business, the people who are running those businesses should look at their customers and say, "Given these new tools at my customers' disposal, how should we reshape this?" And I think that is potentially disruptive innovation in a positive way.

What we as an industry need to deliver are seamless experiences -- however those things are accomplished -- to do the appropriate thing in the browser and the appropriate thing on a laptop or on a device to solve that problem. So the way I view it is, first generation "software as a service" really just meant browser. Second generation means weave together hardware, software and services to accomplish a specific solution. The iPod is a great example of that. You have hardware, the embedded software on the device and an associated [online] service. The BlackBerry is another great example [of the combination of] hardware, software and service. The Xbox is a terrific example -- you've got amazing software in the games, hardware to support it and Xbox Live as a service.

If anybody has a software and services model, it's Adobe, because of that rich [Flash Player] applet that they extend the browser with. The more they enhance that, as you can see in their Flex and Apollo plans, the more it becomes this unified software and service vision, which is basically the same as Microsoft's vision.

In my view, we only have one shared future as a software industry. And that is centrally deployed code that has a different lifetime associated with it on the device it's deployed to. So, what is HTML or DHTML? Most web pages have JavaScript in them. That's code that is delivered to the client and it has the lifetime of the browser instance you're using. Flash -- what is that? Well, it involves enhancing the browser runtime by downloading code. But it tethers those enhancements to the service and the lifetime of those things is still within the browser. With Apollo, maybe you can make the lifetime that of the user on that device. They have increased the lifetime from the browser instance to the PC.

The guidance that we are giving the development community -- and the guidance that we use in-house -- is to look at applications through the following lens: When the business model behind that app means that you have to get it everywhere, we call that the "universal web application pattern." When the most important thing is the experience that the user has with that application and you might be willing to trade off the breadth of the web for the richness of that experience, we call that an "experience first pattern."

History has shown that any time you have a fairly significant market leader, the best way of competing is not to just simply take the same approach. You have to find your own unique approach. And Microsoft has a number of different ways that we could do that because of the different touch points we have with the market and how people use our products.

In the past, success for a software product was shipping, releasing to manufacturing. Today I refer to that as the "grand opening." It's not when things end, it's when they begin.

Things always occur through both leadership and grassroots mechanisms.

The purpose of collaborative software and, in my view, leadership, is to try to figure out the right way of structuring to reduce coordination costs. As systems get bigger, unless you intentionally reduce coordination costs, things explode.

If you declare that everyone [should] use something that's already fully debugged and out there like a standard -- HTML [for example] -- that actually reduces coordination costs. Everyone can rally around something that works. But if it's telling everybody to rally around something that's still in the process of being defined, that causes combinatorial explosion in coordination costs.

Designing Good API

Kode Vicious in ACM Queue has something interesting to say on designing good API. Some excerpts:

The first problem is that certain things, which ought to be passed as arguments, are encoded into the function name itself.

The next problem with this set of APIs is that they are very likely going to be implemented by a set of copy/paste operations....When code is copied and pasted thoughtlessly, bugs are replicated and then are harder to fix.

Human short-term memory has, on average, seven places to store things. If you're going to ask people to remember something extra, you better have a very good reason for doing so or they'll soon forget

API design is an iterative process. First you provide what you think the users need, as well as an escape valve such as ioctl. After a while you see which functions people are providing via the escape valve and you standardize those in your library as full APIs. Repeat until done.

Passing ACLs from windows to Samba

I was trying to copy a file to Samba exported partition from Windows. When ACLs are stored in Samba store (i.e. the store which Samba exports), the users and groups must be mapped to that on the Samba machine.

This is generally accomplished by mapping the SIDs (Security Identifiers), that windows uses to uniquely identify a user. Unix does not have any notion of SIDs. But Samba users(local Unix users who also have a Samba account) do have SIDs associated with them mainly for the purpose of mapping windows users.

The SIDs can be set (else, Samba generates one automatically) by giving it along with pdbedit -a -U command. Then the mapping happens properly.