Warren Buffett: “A simple rule dictates my buying: Be fearful when others are greedy, and be greedy when others are fearful.”

Joe Brockmeier: “The most valuable thing I ve learned watching Fedora is this: Patience. It takes time and steady, incremental growth to build a solid community. If you d asked me two years into Fedora s development whether the project would succeed, I d have been somewhat skeptical, but looking at the project five years down the road, I m convinced.”

Glynn Foster: “Get. Use. Learn. Love. Spread. Only then, in my opinion, can we even think about Contribute…”

Dalibor Topic: “Finishing governance before finishing bootstrapping is a bad idea.”

Jonathan Schwartz: “We announced big news today - our preliminary results for our fiscal second quarter, and as importantly, that we’re acquiring MySQL AB.”

Simon Phipps: “We’ve got an exciting development bubbling that I hope to be able to announce in full detail at FOSS.IN in Bangalore on Friday when I speak there. Just to give you a glimpse of what’s happening, Sun will be announcing a multi-year award program in support of fostering innovation and advancing open source within our open source communities…”

Matt Asay: “[F]ocus on maximizing abundance, and then sell value around minimizing the complexity inherent in abundance.. The old model was to assume that the value was in the software itself and to therefore lock it up. It turns out, however, as Tim O’Reilly notes, that data is the real value, not bits and bytes. You don’t discover or, rather, uncover, that value until you have abundance.”

Jonathan Schwartz: “[L]ater this week, we’re going to use our defensive portfolio to respond to Network Appliance, filing a comprehensive reciprocal suit. As a part of this suit, we are requesting a permanent injunction to remove all of their filer products from the marketplace, and are examining the original NFS license - on which Network Appliance was started. By opting to litigate vs. innovate, they are disrupting their customers and employees across the world. “In addition to seeking the removal of their products from the marketplace, we will be going after sizable monetary damages. And I am committing that Sun will donate half of those proceeds to the leading institutions promoting free software and patent reform (in specific, The Software Freedom Law Center and the Peer to Patent initiative), and to the legal defense of free software innovators. We will continue to fund the aggressive reexamination of spurious patents used against the community (which we’ve been doing behind the scenes on behalf of several open source innovators). Whatever’s left over will fuel a venture fund fostering innovation in the free software community.” Bravo.

Jim Grisanzio: “What I find interesting is that Matt uses the phrase ‘we’re getting Solaris versus Linux’ to point to an article titled ‘OpenSolaris will challenge Linux says Sun’ which is actually an abridged article from the more aptly titled ‘Sun: Coders key to Solaris’ rise’ published last week. I blogged about that original article because I loved the quote in there about the OpenSolaris Community. But the version that has people all worked up today is missing eight paragraphs of text from the original. Why? Read both of them and you’ll see the clear difference in tone. And why all the wild headline changes, too? Even if you read the version Matt points to you’d be hard pressed to find anything in the article to substantiate the headline. I mean, really, this is silly. Sun’s Ian Murdock and Marc Hamilton were talking about how the OpenSolaris community is growing, how the technology is improving, and some of the plans we are kicking around to improve things. That’s pretty much it. So, where’s the war here?”

I was in New York this past week meeting with a bunch of Sun customers and speaking at several Solaris related events. On Wednesday, just before 6pm, we were on a conference call in the Sun office at 101 Park Ave. when we heard a noise that sounded like thunder, and the whole building shook. When the noise didn’t stop, we stepped into the hallway and looked out the window to see 41st St. filled with what appeared to be smoke, debris hitting and nearly breaking the window, and people running down the street en masse. We filed down the stairwell and emerged into a scene straight from 9/11—shocked looking men in suits covered in a layer of brown debris, masses of people hurrying down 40th St. as fast as they could dashing across streets without regard for the traffic, cars honking their horns trying to get away through the throng, sirens blaring, cell phones not working, policemen doing their best to maintain control, people crying and holding each other, necks craning to see a plume of “smoke” rising into the sky high enough to obscure the Chrysler Buidling, and that awful roar that just wouldn’t stop. Of course, the “smoke” turned out to be steam, and the roar was the steam blasting out of an enormous crater on 41st that turned out to be just outside that window. But at the time, no one had any idea what was going on, and with lack of information comes speculation: It’s rush hour, they’ve blown up Grand Central Station, what’s next and when? It took a good hour before anyone knew it was just a steam pipe and nothing sinister. All in all, it was a pretty extraordinary experience that’s going to stick with me for a long time.

Just stumbled across the button “Check guest and resource availability” when adding a new appointment in Google Calendar. Sure enough, when clicked, a nice little window pops up that allows you to find slots of free time in common across invitees. Not sure if this is available across all of Google Calendar or if this is a Google Apps Premium feature (I’ve had imurdock.com in GAFYD for a while now and upgraded over the weekend). One problem is immediately apparent though: It only appears to be checking the main calendar (I actually have several calendars—work, home, travel, etc.). This is a problem with the SMS interface too, which only appears to operate on the main calendar.

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!

Simon Phipps: “Stewart is spot-on with Flickr’s policy and paradoxically will keep my business by allowing me to leave at any time.” Absolutely. This post nicely explains something I’ve noticed about my own actions recently, namely why I’ve remained a del.icio.us user even as I’ve become less than enthralled with its new owner: I can export my data at any time from del.icio.us and take it to a competing service. As Simon so eloquently explains, I remain a customer because it’s easy to stop being one. To compete, a rival service needs to not only provide a better product but also make it equally simple to take my business elsewhere, and most service providers don’t seem to be in any hurry to let me do that. Furthermore, the usual reasons for moving data elsewhere, better integration with other providers’ services or more compelling features in a competing service, are less important when the service I’m already using has an open, well-documented API that allows me to do whatever I want with my data without needing to export it.

I was in Russia last week to speak at Interop Moscow 2006. As an American who’s old enough to remember duck and cover, it was an experience indeed. Growing up, the Kremlin would have been the last place I’d ever thought I’d get a chance to see, that is, if I’d thought about such things back then (most kids don’t, and I was no exception, being too busy thinking about important things like baseball and computers). After the conference, I did get that chance to see the Kremlin and other Moscow sights with fellow speakers Jon “maddog” Hall, Federico Biancuzzi, and Raoul Chiesa. Speaking of being a kid and computers, I also had the opportunity to meet Steve Wozniak, cofounder of Apple Computer. I was first introduced to computers when my father replaced his typewriter at work with an Apple II in 1981 or so, thought I might find it interesting, and brought it home to show me. Needless to say, it captured my imagination, first with the games, then with the idea that I could make it do my bidding with a little study and a lot of tinkering, and I’ve been hooked ever since. So, as I had a chance to tell the Woz firsthand, I literally do what I do because of his Apple II. I took plenty of pictures, but as usual, I don’t like most of them. The ones I don’t end up throwing out will be appearing in my Flickr photostream over the next few days.

Robert Love: “In Google’s calculation, the cost of a native port outweighed the benefit of a native [port] v s-a-v s a WINE-fueled Picasa. Is that really unexpected? Our development platform is no shining star. We have two toolkits, poor binary compatibility, and unclear direction. To be sure, vendors such as Novell are devoting increasing effort toward improving the Linux ISV and platform story. But the community must make it a priority as well, from the kernel up through the highest levels of the graphical desktop.” That’s part of it (and certainly an accurate assessment of the kind of thinking we need as a community to make Linux a better platform). I think there’s another part of it, though, and that’s that operating systems in general are fundamentally uninteresting to Google as platforms in themselves, as well they should be—after all, the web is Google’s platform, and they dominate there, so why should they promote an alternative where they are much weaker? In my view, the (fat) client bits merely exist to ease the transition from the current, predominantly desktop centric world to a new web centric world where Google naturally thrives. After all, such paradigm shifts are always gradual. There’s the offline question too—if all your data is in the cloud, how do you get to it when you’re not online?—though I suspect over time the browser will provide offline capabilities of some sort, so this is largely a temporary problem too. So, using Wine in ports not only minimizes the incremental cost of building out a foothold on the client (which, again, is a necessity for Google, given that Google’s biggest competitor is between them and 90% of their customers), but it raises the fat client platform up a level too. In other words, it builds a fat client platform with a consistent look and feel across desktop environments; and with this, the operating system underneath rapidly becomes irrelevant. The real question is when Google will hook Picasa into a photo sharing service of its own. I already keep my photos in the cloud, and I’d love to organize and edit them in Picasa (Organizr is nice, but nowhere near as nice as a desktop application, and it doesn’t have some basic functionality, like import from camera and red eye repair). Of course, this is just one example of Google having some platform thinking issues of its own, though that’ll have to be a rant for another day.

I’m taking Rojo for a spin, mostly because of recent upgrades that add some interesting features, including a “sort by relevance” function that lives alongside the usual “sort by date”—a “personalized digg”, as some have called it. One thing I like about Rojo is that it’s a River of News style aggregator, which means all feeds get combined into a single stream that’s very easy to scan for interesting items, rather than serving as just another way of filling my inbox with stuff I won’t have time to read anyway (the “aggregator as an extention to the email client” model). With River of News style aggregators, it’s no big deal if you miss something, kinda like it’s no big deal if you don’t read every last article in the newspaper every morning. Trouble is, how do you make sure you read the most important stuff first, so in the event you don’t get through everything, the likelihood you miss something is small? “Sort by relevance” would appear to solve this problem nicely. Rojo appears to calculate “relevance” by analyzing a few things: What I read (i.e., what I click on), what I tag (either by giving it “mojo” or by tagging it in the Web 2.0 sense of the word), and what my contacts read and tag. That seems like a reasonable enough algorithm. Problem is: 1. most of the things I read Rojo doesn’t know anything about (they’re in my browser clickstream); 2. I already have about a year’s worth of tags accumulated at del.icio.us, and I have no intention of moving those tags anywhere else (ironically enough, because del.icio.us gives me the ability to do just that); and 3. I already have more social networks and contact silos than I know what to do with, and I certainly don’t want another one. So, Rojo’s new features are less interesting than they appear at first glance. Guess I’m going to have to continue doing without, either until I decide to dump all my stuff in one place (ahem) or until small pieces loosely joined evolves a bit further. Update: On second look, it looks like relevance is actually calculated by the total number of reads and tags rather than by the number of reads or tags by me or my contacts. Not sure how that can be called personalized, but I guess those are the words of others, not Rojo’s.

I’ve just returned from Istanbul where I spoke at zg r Yaz l m ve A k Kaynak G nleri 2006 (Free Software and Open Source Days 2006). I was last in Istanbul in 2004, and as then, I had an amazing time. Photos will be appearing in my Flickr photostream over the next few days. Thanks again to everyone who took the time to show me around and otherwise entertain me, especially Boran Puhalo lu, Sinan Tunal o lu, Nazl pek Mavu o lu, a l Ulu ahin and Haldun Bayhantopcu.