Mar 2004
Fri, 26 Mar 2004
Cobind Desktop Linux
We finally got the company website launched this week. The company is called Cobind and our first product is called Cobind Desktop Linux.
Distrowatch initiated coverage of us today with a story on the Distrowatch homepage and our distribution details. Thanks to Ladislav Bodnar at Distrowatch!
We're a small startup from Pittsburgh funded by a fellowship and having no official office space. That means we telecommute, if that's still what it's called. I should know, I was telecommuting from my home in Redmond 5 years ago to an office in Boston. The real story there is that the tools, particularly software, for distributed work have gotten so much better in that time period that I actually believe the economists are right about productivity gains.
It's funny because I distinctly recall saying that I did not want to be in the operating systems business last year. It's like working at Microsoft with all of the downsides and none of the upsides.
It's a weird situation to be a starving startup in Pittsburgh right now as the city is falling apart at the seams and it's not clear that it's ever going to recover from hemorrhaging so many educated young people. Anyhow, we've stuck our stake in the ground and tried to do the right thing by creating something new. That's what I call accidental entrepreneurism.
Whether this large company town can learn to nurture or retain small companies is yet to be seen. Oh sure, there have been a few, but nothing like the numbers that you see in a big tech city. I remain hopeful and that's saying something. A lot of credit goes to Idea Foundry and my friend and business partner Bryan Mills. I'd probably have left the city last summer had it not been for them.
We are fortunate to be able to leverage open source in much the same way that American companies would leverage outsourcing. Of course, with open source you've got a lot less control of the product until it gets into your hands at which point it becomes a question of the classical software development triangle: resources, features, and schedule.
The ideas that formed the basis of our products began last summer when we were working on designing hardware appliances. We discovered that creating a custom linux distribution is not a trivial undertaking and set out to solve that problem.
In the process, we discovered that we could go from a product concept, such as the aforementioned desktop, to a bootable installation CD-ROM or bootable live CD, in just a few days. As we continue to bake the tools even further, abstracting OS metadata in the process, it just goes quicker, with less cost, greater repeatability, you know the story.
A lot of the ideas that are implemented in our build tools were strangely prescient with regard to Ian Murdock's ideas in Towards a New Kind of Linux Distribution. The componentization of Fedora Core Linux - what a concept! We had shown our first demo of this technology in October 2003.
That's all for now. We'll have more coming in the near future. This software company stuff is likely all you're going to hear about from me for the foreseeable future. It's occupying nearly 18 hours a day for me now and there's not much time for things like blogs or taxes. I've got some public speaking engagements coming up this summer and I'll mention those as they get closer.
Posted at: 03:38 | permalink
Wed, 03 Mar 2004
Everybody Weighs In On Open Source UI
I started writing this as a comment to Don Park's piece which is a reaction to ESR's piece on open source UI. I thought ESR's piece was really good in that it patiently unearthed the difficulties of such software. Sam Ruby covered John Udell's investigation into the problem as well. My reaction got long and complicated enough that I didn't feel like a comment was the right place for it.
What the open source world needs is not more groups or more widgets. Most of what's wrong with open source UI can be explained in a single book titled The Paradox of Choice: Why More is Less by a Swarthmore professor named Barry Schwartz.
Part of the responsibility of the UI and in turn, it's designer, and I think what ESR was getting at, is to eliminate choices that make no sense. This interview with Ethan Diamond of oddpost fame describes the problem rather succinctly. Diamond says, "So, we started with the basic three-pane layout familiar to users of Outlook, Eudora, ccMail, and so on, and then we systematically eliminated every non-data pixel from the screen."
Fundamentally, I think this is one of the hardest things for a coder to do because it involves throwing away your baby, which is anathema to the culture. The best designer you can get is going to function largely in the form of "no one cares about this so you should get rid of it". Enough has been written about what's wrong with the culture in terms of not on-boarding UI design people and so guys like me who operate in code and UI is about as good as it's going to get without a major cultural shift.
The best groups do this before the code ever gets written, but in the open source world it's more likely to operate in the form of hack a prototype, then eliminate stuff, as you see guys in the gnome lists refer to "HIGifying" applications.
I spent the last few days hacking nautilus to get rid of the next to useless information view in the sidebar and default to the tree view. Nielsen would say that it's a matter of precedent, people expect a tree view when they launch a file manager, but Andy Hertzfeld at eazel spent some time coding the information panel in what was I'm sure an attempt to copy the Microsoft pie-chart-of-my-disk view that appears in My Computer. The problem is when you combine the information panel with a default right pane containing the user's home folder, you add no value.
Making a UI change to nautilus like this should have been rather simple but for some strange reason, the architecture has all of the views save for the information panel implemented as component plugins that are enabled via bonobo activation. The information panel is the only one that's not a plugin, which makes the code look a bit odd since the information panel is hard coded in nautilus and makes it harder than it should be to implement the kind of change that I described above.
It's not clear to me why information panel wasn't implemented as a component plugin to be bonobo-activated like the others. Then, setting up defaults is merely a case of which plugins are enumerated in the bonobo query. While this sounds fundamentally complicated to the uninitiated, it's something I could easily describe to a UI guy, "Simply look at ...
/usr/lib/bonobo/servers/Nautilus_View*.server
and remove the ones you don't want". Compare that to what was actually required which included the bonobo step as well as a little /**/ in the C code and the usual configure-make-make install and you realize that you have a UI that is expensive to change, owing to the fact that it requires someone who knows the ins and outs of a C compiler, which may have been what Don was getting at in referring to separation of concerns. In this way, you can see that the architecture of the application directly influences the UI in terms of placing very real engineering costs on changes to the UI.
Finally, consider what this means in terms of the GPL. My addition to the code was "/**/" and a couple make hacks. In real terms, this removed parts of the application. If I contribute according to the terms of the GPL, I may have improved the UI in usability terms depending on your perspective, but I've subtracted code in terms of sheer line count metrics. Hmm...
Posted at: 10:56 | permalink
Social Networking Software That Doesn't Suck
It's a dog eat dog world out there.
Posted at: 01:23 | permalink
