« March 17, 2003 | Main | March 19, 2003 »
March 18, 2003
Transparent Coding
K. S. Shankar (Doc) from IBM just said something which is similar to a comment that Michael Bernstein made via email earlier. Michael said "the knowledge that other people will be reading your code (whether shallowly or deeply) has a significant effect on how you code." What Doc said is a corollary: when people find a bug that you're responsible for, its embarrassing and people will work hard to fix them quickly. The point is that it comes down to transparency and the value that it has in many circumstances. I'm a fan of transparency as a tool for driving correct behavior in organizations. When you apply it to individuals it gets trickier. All kinds of privacy questions.
02:57 PM | Recommend This | Print This
Optimizing Commanilties and Differences
What few things need to be the same so that everything else can be different?
This question, poised by Michael Tiemann, CTO of Redhat, is at the heart of many of the decisions facing IT today. This question defines the power of web services as well as the move toward managed desktops in corporations. Finding the balance in this question is a critical decision facing technologists as they develop enterprise architectures and operating models so that IT can serve the business.
12:38 PM | Recommend This | Print This
Microsoft's Shared Source Initiative
Jason Matusow is the Shared Source Manager from Microsoft. I notice that he's not wearing a name tag. I'd bet that isn't accidental: Jason started his talk by referring to the scene in Hitchhiker's Guide to the Galaxy where cows are brought out so that people can be introduced to their dinner. The audience appreciated that analogy. He opened by making these points:
- Access to source code is not the primary concern for most people
- Having an option to work with the source code is important to to a few individuals and many organizations
- Few people who have access to the source code actually use it
Jason points out some common myths:
- The is a "right" software development model.
- Contrasting "open source" software with "commercial" software. Much open source software has commercial interests.
Now we get to the heart of the talk: there is a move by traditional software vendors and open source software vendors to move to the middle and find a business model that works better than either has in the past. Microsoft's Shared Source initiative (SSI) is evidence of Microsoft's steps in this direction.
SSI is not open source. Rather, its an initiative to share the source under certain conditions with customers, partners, and governments world-wide. Someone in the last session I was at (actually it was David Sklar who wrote the PHP Cookbook) suggested that SSI created a situation where source is closed only to those without means. From a security standpoint, there is no closed source OS. Someone with the right resources has access to the code whether its Windows or Linux.
A pessimist will look at this as a disinformation campaign by Redmond and indeed, there's certainly a PR aspect to it. I'm by nature an optimist and I view it as evidence that the open source community is having an impact and driving change in traditional high-tech companies like Microsoft, Dell, Oracle, and Novell. We have to be happy about that.
10:14 AM | Recommend This | Print This
Dell's Support for Open Source Software
Craig Lowery is a Software Architect and Strategist for Dell. Much of his talk was interesting, but not particularly new. However, he highlighted this statement and it caught my attention:
Dell believes that all the major pobjections to OSS have been addressed and its ready for the enterprise now.
This doesn't mean that they're ready to start shipping Linux on the desktop again, although Craig says that they're reconsidering it.
08:14 AM | Recommend This | Print This
Openness As an Inherent Good
Yesterday, Fazal Majid reacted to my post on Whit Diffie's talk by saying:
I don't really buy this argument [that more eyes looking at code make it more secure] - unlike ordinary bugs, security reviews like the ones done by the OpenBSD team require a strong commitment and extended effort. They are not likely to arise from casual source reading.
Fazil, of course, is right. Finding bugs in general, and security issues in particular, requires a purposeful, planned, carefully executed review. This morning, almost in response to this issue, Mary Ann Davison from Oracle is discussing open source software evaluations. Specifically, Oracle is going to conducting (i.e. paying for) an EAL2 certification of RedHat's Linux Advanced Server product for use with Oracle DB. She makes the point that Oracle evaluates products all the time and when they do that, third party teams look at their source code.
On the other hand, I think that the argument restated by Whit yesterday (although not necessarily espoused) is a little more subtle than what its simple retelling in a talk (or blog) can convey. Its not so much that random eyes looking at code will make it more secure. The issue comes down to a basic philosophy of openness and its inherent goodness. As anyone who's read The Transparent Society by Daniel Brin knows, making this argument is much more involved than a simple sentence.
Having recognized softare openness as inherently good, I don't want to be misunderstood. I do not believe that this makes companies who close their source code inherently evil. I would, rather, view them as not having yet recognized the benefits of an alternate strategy.