Friday, Apr 4, 2003

I had an interesting experience yesterday when I was asked by Mike Sax to come to the Oregon capitol building to testify against HB 2892, known as the Open Source Software for Oregon Act. In general, the bill talks about the benefits of open source, open standards and open data formats, most of which I didn’t have any issues with. However, I got up at 6a and drove an hour down to Salem because of the following clause:

“(2) For all new software acquisitions, the person or governing body charged with administering each administrative division of state government, including every department, division, agency, board or commission, without regard to the designation given the entity, shall:
…
(c) Provide justification whenever a proprietary software product is acquired rather than open source software;”

By requiring state government employees to write a special justifications, this bill erects artificial barriers to adopting commercial software, above and beyond the fact that commercial software requires an initial payment (which should be more than enough of an edge for open source software).

If you’ve never been to a government bill committee hearing, I highly recommend the experience. I was in a little hearing room with a bunch of other folks, all interested in this particular bill. I signed my name on the list of folks “against” the bill so that I would have a chance to testify. The chairman called first proponents of the bill and then opponents up to the microphone three at a time.

Some of the the proponents were teachers and school staff that had put Linux and other open source software to good use in combination with old computers used as thin clients against a back-end server (using X-Windows, I assume). They claimed that they solved themselves all kinds of trouble because open source software was “immune to viruses and security problems” (now *that’s* effective propaganda! : ). Some of the proponents were embittered IT staff and new college grads looking to bring some old-fashioned democracy back into a country that had been recently taken over by corporations. It was all I could do to avoid pointing out to them that that the country had been taken over by corporations shortly after Adam Smith wrote “The Wealth of Nations” in 1776 and the budding US government adopted the ideas therein to fund their new country. The basic story of the proponents was that open source was good, so it should be mandated over closed source.

The opponents, on the other hand, were largely suit-wearing fellows from large groups of commercial software corporations (one of which didn’t hesitate to remind the esteemed committee that it’s member companies had paid $135M in Oregon state taxes last year). Their arguments were that undoubtedly open source software was clearly already being used by government bodies, that there was no rule against it and that their should likewise be no rules against proprietary software. Only Mike, owner of a small Oregon-based software company, and me, owner of nothing at all of interest, represented the “little guy” on the opponent side (we stuck out because of the lack of either a neck tie or a suit coat).

19 copies of my written testimony were submitted without comment at the request of the chairman who assured the audience that all testimony would be read. My verbal testimony was limited to pointing out that shackling proprietary software was “bad engineering” because it could easily cost the state of Oregon more money in the long run; maintaining source code is a lot more difficult than maintaining commercial software for normal humans. I also pointed out that being open source did not prohibit viruses or security problems; the first computer virus ever was written on a Unix, the predecessor to Linux and that they share an identical security model. To be fair, Unix wasn’t open source, but I stretched the truth less than the open source guys, so I didn’t feel too bad (Unix was “source available” at the very least  : )  And finally, I let the committee know that open source didn’t mean open standards or open data formats and that, in fact, those were things that commercial software companies had done the most to bring into greater use over the years.

Having never done anything like that before, I wasn’t sure how well I’d done, but one of my fellow panelist (a procurement officer from another giant suit-wearing organization) wrote “nice job” on his pad of paper while his colleague preached the wisdom of “amending the language” of the bill to be more “practical.”

At the end of the hearing, the chairman of the committee called out some names of the most credible, suit-wearing fellows from each side of the debate to form a working group to come up with a bill that the committee could actually consider submitting for a vote. The sub-text was that the bill as it currently stood was pretty silly; it didn’t allow any greater freedom to pick open source software but it did limit the ability to choose proprietary software, which wouldn’t make those Oregon software company tax payers happy. This seemed a most sensible conclusion to me and gave me confidence that our government isn’t so screwed up after all.

When the room was cleared, I was assaulted by one of the open source proponents, reminding me that Unix wasn’t open source and that Linux would never have any such problems (which makes the presence of virus protection software for Linux seem like a very poor business decision). I was also cross-examined by a tall, thin, balding, old-ish man with the longest grey beard I’ve ever seen in person. He seemed very knowledgeable and was very interested in the details of my opinions. He reminded me of nothing more than a fallen Richard Stallman in 30 years and added to the surreality of the morning.

On the way back to our cars, Mike thanked me for coming and asked if I was glad that I’d come. It surprised me to learn that I was. Not only did I feel that my “just a guy” presence helped the suits make their case, but I felt like I was doing my duty as a citizen. Who knows, this experience might bring out the politician in me. I’m sure I could do at least as well as Jessie Ventura. : )

Chris Sells
Sells Brothers, Inc.
8539 SW 166^th Terrace
Beaverton, OR 97007
http://www.sellsbrothers.com
csells@sellsbrothers.com

Oregon State Representatives,

My name is Chris Sells and I run a one-man software consulting firm from my home in Beaverton, Oregon. For more than 20 years, I’ve been pretty much everything you can be in the software world: software engineer, chief architect, director, author, speaker, consultant and even marketer, so I know software ins and outs pretty well. In addition, I’ve been the treasurer for the Cooper Mountain Elementary School for the last two years, so I’m familiar with how important computer-related purchases are to at least one branch of the Oregon state government and how those decisions get made.

Before I start my testimony, I’d like to tell you about my experience in my high schools’s band. I played the trumpet for seven years, four of them in the marching band. I wasn’t great, but I loved to play. It gave me a deep feeling of satisfaction to be part of the band and to perform for the audience. I even continued my playing into one semester of college band, but it just wasn’t the same. The band at that level required a degree of skill and professionalism that I just didn’t have. Once I figured out that I didn’t have what it took to be a professional musician, I went on to find something else to make my living (computers).

By and large, open source software is often very much like a high school band. No one cares about the money. An open source programmer just wants to have their work seen and appreciated, regardless of whether they’re good enough, or thorough enough, to be paid for it.

Sometimes a high school band will be amazing; easily good enough to compete at any level. However, this is very rare when compared to professional bands that get paid based on how well they entertain their audience. Likewise, sometimes open source software achieves the same level of quality as closed source software. In those cases, I?m completely in favor of considering open source software to solve Oregon?s software needs. However, I?m not in favor of mandating open source software, which is what HB 2892 does.

By putting up artificial barriers to entry for closed source software, Oregon is narrowing their choices to those rare cases when open source software lives up to the letter of the requirements for a Request for Proposal (RFP) but doesn?t provide the same level of thoroughness that competing for money on the open market requires. This narrowing of choice is going to cost Oregon considerable additional funds in support, training and documentation, all things that the open source community lives without because of their own level of expertise. Continuing the analogy, assembling your own electric guitar if fun for an enthusiast, but requires very specialized skills. Likewise, using, supporting and maintaining open source software requires real engineering skills, which is the hidden cost you don?t see when initially installing open source software.

In addition to mandating open source software, HD 2892 calls for open data exchange standards. This is something that I?m very much in favor of. The latest and most general purpose standard for open data exchange is called the eXtensible Markup Language (XML) and is fully embraced by both the open source and the closed source communities. However, it?s the closed source vendors, like Microsoft, IBM and BEA, that are really making XML a reality by pushing it into their software at all levels. In fact, these same closed source vendors as going beyond just XML and building standards for communicating data between computers based on open source and closed source operating systems to make sure that all computers can communicate with each other. These standards are called ?web services? and are based around the Simple Object Access Protocol (SOAP). Defining, implementing and testing standards is an expensive proposition involving man-decades of dedicated engineering work, which is why it takes companies that make money on software to turn them from an adolescent dream into an adult reality.

I believe that open source should absolutely be considered for the state’s software needs. However, being open source is but one quality that needs consideration. Things that also need to be considered include the cost of training, documentation, support, upgrading and maintaining software systems and their support for open data standards. Some open source software will achieve the level of functionality and attention to detail that Oregon needs, but artificially narrowing your choices to open source software is like open picking high school bands to play at the Rose Garden. Sometimes you’ll get lucky but more often the audience is going to demand a refund.

Thank you for your time and attention,

Chris Sells

Tue, Feb 18, 2003

The buzz was all around VSLive last week about Microsoft patenting the .NET Framework API. In fact, an eWEEK reporter asked my opinion and this is what I said:

I’m no patent attorney, but in examining the patent application, it looks to me as if they’re claiming a patent for the entire .NET Framework, which comprises the classes that a .NET programmers uses to get anything done. My understanding of the patent laws says that Microsoft has every right to do this, since they invented it. The reason for them to do this is so that they can maintain control of its implementation. Hopefully Microsoft will grant a royalty free license to all implementations of the CLI ECMA standard, which makes up a large percentage of the .NET Framework, or that standard will be worthless.

Even if they grant such a license, projects like Mono are still vulnerable. They plan on implementing even the parts of .NET that aren’t standardized, like ASP.NET and WinForms. This would allow Windows programs compiled against .NET to run under Mono on Linux, providing a single API for cross-platform applications. This has been tried and failed in the past as recently as Java, but I had hoped that the Mono guys could make this work. When Microsoft is granted this patent, they can shut down the non-standardized parts of Mono whenever they want. That’s good for Microsoft share holders, but it’s not good for 3rd party developers that want to write cross-platform solutions.

What I should have added is that as far as I know, Microsoft hasn’t ever enforced its patents. Apparently they keep them for defensive reasons only. Or, they could be waiting ’til they have a critical mass of patents, enforce them all at once and win the game of Risk that they’re playing with the world. : )

Friday, Feb 7, 2003

In response to Never Send An Email In Anger, Lars Bergstrom recommended that I set up a rule that defers sending an email for 1 minute. I set it for 2 minutes under Outlook XP like so:

• Tools->Rules Wizard
• New
• Start From A Blank Rule
• Check messages after sending
• Which condition(s) do you want to check? -> None
• This rule will be applied to every message you send. Is this correct? -> Yes
• What do you want to do with this message? -> defer delivery by a number of minutes
• a number of minutes -> 2
• Finish

And it works like a charm. It’s always w/in the first second that I wish I could recall a message, so two minutes should be more than enough. Wahoo!

A friend of mine pointed out to me the other day that the C in CLR stood for “Common,” that is, the CLR provides the same services to all languages. In fact, at this date, C# and VB.NET are really just “skins” over the CLR and provide nearly identical functionality. With that in mind, why are we still fighting the language wars? There are several reasons:

• VB and C# programmers are just culturally different. They come from different backgrounds, different educations and different points of view. Remember that VB was initially invented to let non-programmers program. C++ programmers came from folks building operating systems. Those roots are still evident today.
   
• The VB and C# product teams are different and gain benefits based on how many of each kind of programmer there are. Based on that, do you think that those teams are going to pound the “all languages work great under the CLR” or the “C#/C++/VB.NET rocks” drum? Which message makes you look best at review-time?
   
• Languages *should* be different. Managed C++ does that cool managed code/unmanaged types thing. Eiffel# does Design by Contract. Perl.NET has obfuscation built in at the source code level, alleviating the need for a 3rd party tool. The fact that VB and C# are virtual clones of each other is a mistake that I hope is rectified. Frankly, I hope that VB goes back to it’s roots of enabling non-programmers, as that’s a huge hole in the current list of managed languages. Certainly C# is going back to its roots by adding generics et al in the next version.

I’ve found that the “Common” means that teams can use the same language at more levels of their system, i.e. no more VB for this, C++ for that, script for this other thing. Now it can be all VB or all C# (or almost all, ’til Yukon ships) and the number of different kinds of programmers needed for a single project goes down. That provides a real benefit to companies trying to keep costs down and quality up while still allowing the team to decide what language features are important to them. This is goodness.

With the increased shared capability at the runtime level, I’m actually hoping that language motivation will increase. I think that there’s still a lot left to do to make the programmers more productive and the motivation for one language to gain ground over another is a good thing. Plus, I still have an excuse to make fun of semi-colon-challenged programmers and what could be better than that? : )

Reading a very interesting book which I’ll discuss in a future post, I came to a startling conclusion. As much as I love OO thinking and programming, OO databases are never going to fly. I realize that this may not be so startling considering how long OOD products have existed and how unsuccessful they’ve been so far, but the conclusion I came to was *why* they’ll never fly. The reason is simple: the data itself is more valuable than the programs that use it.

For an OO guy, taught that behavior was everything and data was an implementation technique, that’s a startling conclusion. However, the beauty of a database is that it’s devoid of behavior, or, if there is behavior, it’s layered in on top of the data. Programming languages come and go along with the ideas that underlie them and the applications that are built with them. Relational data, on the other hand, is a model that’s simple enough, but complete enough, to move forward from application to application, accumulating value as you go in the data itself. And, since the relational model is so entrenched, no technology for the last 10 years or the next 1000 would be complete without support for it. Even Microsoft, IBM, GM and AT&T will prove to be less enduring than relational data, the tools to program against it and the tools to slice and dice it w/o programming anything (the latter are amazing strong already and continue to grow).

Data in OO databases, on the other hand, are bound to behavior and worthless for anything but the limited set of applications for whom the behavior was paramount and the data an implementation detail. When things change, as they always do, how are you going to get the data out so you can do things different? You’re going to dump it to the simplest, most complete, most firmly entrenched data format that the world has every known — relational data.

OO persistence formats are, by their natural, tied to a specific object model and therefore hopelessly proprietary. And with the emergence of XML, OO persistence formats are going the way of the dodo, even for applications running on machines without a database server. Why would I persist data to a closed format when I can choose relational data for the big stuff and XML for the small stuff? Both provide endless tools for slicing and dicing and bringing forward when the application dies. With OO persistence, when the app goes, so goes the data. The problem with OOD is that things are *too* seamlessly integrated. Ironic, no?

I’ve come to the conclusion that the use of the “sealed” keyword in C# (and the concept in .NET) should almost never be used, at least on a class. Semantically, sealed applied to a class means that a class cannot be used as a base class. For example, the ImageList class from the System.Windows.Forms namespace is sealed:

public sealed class System.Windows.Forms.ImageList : … { … }

What sealed means is that the designers of the ImageList class didn’t take the time to test what would happen in all the scenarios where an ImageList is specified but a subclass is provided, e.g. MyImageListEx2. So, since they didn’t test these scenarios, they’re protecting developers from deriving from the ImageList base class when bad things might happen. They’re also protecting developers if the base class changes radically in the future and derived classes no longer work.

Stop it!

I don’t want to be protected in this way! Instead, I want to try to derive from ImageList and see if it works in the scenarios in which I’m interested. And if future versions of the ImageList base class break my derived class, I want to update my derived class in ways that work across versions of the base class or have two versions or whatever else I need to do to make it work. By making a class sealed, I just don’t have any choice in the matter, which severely limits me in what I can do.

As an example, I think that the current ImageList implementation sucks in the following ways:

• Every time you need to edit an image, you need to remove the old image and add it back again
• Images are too small to see what they are
• Can’t tag images with names

So, I’d like to build my own ImageList implementation that has the exact same programmatic interface, but that pulls images from manifest resources, fixing most of the issues above. All of the controls that take images get them from an ImageList type, so I need to provide my extra functionality in a type that’s compatible with ImageList. However, the only way to do that in .NET is via inheritance and the damn sealed attribute disables my ability to do that! Instead, I have to build a custom component that’s also an extender provider if I want to provide the same design-time usage as an ImageList and I have to tell developers using my image list component not to use any of the ImageList-related properties because it will conflict with mine. I literally can’t package my functionality in a way that’s developer-friendly in the same way as the ImageList and it’s all because it’s *sealed*!

Of course, the ImageList class isn’t the only one. I had a solution to the problem of asynchronous method calls to web services from WinForms apps the other day (the problem is that an extra hop is always required to get back to the UI thread), but my solution can’t work because the base delegate type required to make an asynch call is sealed. And the list goes on and on of things that I can’t do because somebody is “protected” me from potential bad things.

Please, please, please, please, please don’t mark your classes sealed. If you do, folks that want to provide extended functionality, and test to make sure that it works the way it’s supposed to, don’t even have the option. Type compatibility is a huge deal when you’re dealing with class-based abstractions instead of interface-based abstractions and using the sealed keyword throws all of that away. The C++ community survived very nicely without sealed for a decade and it’s made half of the classes on my site possible.

You took away my deterministic finalization. Must you also take away my ability to derive?

I just flew in from 2002:

• Wrote or co-wrote 4 books: Mastering VS.NET, Windows Forms for C# Programmers, Windows Forms for VB.NET Programmers and ATL Internals, 2/e (you should see them all in 1H03)
• Helped Don & Shawn with their books (no writing, just heavy-duty feedback)
• Wrote 6 articles for the Wonders of Windows Forms column (some are excerpts from my WinForms book)
• Wrote 9 articles for the “Chris Sells on .NET” newsletter (some are excerpts from my WinForms book)
• Started the “Adding Ref-Counting to Rotor” research project (we’ve got a alpha running!)
• Wrote a 5-day WinForms short course
• Spoke at bunches of conferences and seminars, including the 2 Web Services DevCons I hosted
• Started a newsletter and published 8 issues
• Started the Windows Developer News forum
• Wrote or co-wrote 13 magazine articles (3 are still pending publication)
• Wrote 29 Spout pieces, including the ever popular VS.NET Fun Facts
• Shipped 3 releases of Genghis
• Shipped several other new tools and samples, including Wahoo!, CollectionGen, XsdClassesGen, imcli and RegexDesigner.NET
• Created the Intel Rich Client series where I served as the editor for 6 articles (1 is still pending)
• Consulted for several companies
• Mentored several proteges
• Conducted a very painful, but very fruitful, marketing survey
• Lost 55 pounds (which I hope never to find again!)
• Answered countless mailing list and direct questions via email

and boy are my arms tired! Even I look at that list and think “holy workaholic, Batman!” Of course, I couldn’t have done all these things alone. I worked with fabulous co-authors and co-contributors. Thanks to you all and I look forward to working with you again in 2003!

In the new year, I have the following goals:

• Make Ask The Wonk a fun experience for all involved (it just started on Monday, but it’s already great fun answering the level of questions I’ve received!)
• Move the DevCons to the phones via the PhoneCons to avoid the expense and hassle of travel for everyone, while still maintain the power and charm of the DevCon
• Get those .NET War Colleges humming! I *so* look forward to these
• Several more releases of Genghis (a new release is already cooking)
• A few more magazine articles (I’ve got a few already in the queue)
• Finishing up the Rotor ref-counting project, publishing the code and the results
• Re-org the web site a bit (again!)
• Continuing the Wonder of Windows Forms column
• Hanging on the Off Topic mailing list (still my favorite mailing list)
• A couple of other projects that I’m dying to share with folks, but am sworn to secrecy…
• Losing another 35 pounds (it’s a 2-year plan)
• Find a way to take a vacation

We’ll see how I do this time next year, especially on those last two.