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.

I concerned Wahoo! patron sent in the following screen shot of the current high scores as exposed by the high scores service:

As you can see, the high scores service has turned into the poster child for the need for web service security. However, after hanging out at two Web Services DevCons and talking with Keith “Mr. Security” Brown, I’ve come to the conclusion that there is no good way to secure this specific web service. Even worse than that, there’s an entire class of web services just like it that can’t be guaranteed secure.

The goal of the high scores web service is to provide access only to the Wahoo! app itself. Only Wahoo! knows when someone has earned their score while playing instead of merely faked it through some other means. Of course, this application is just for fun, so the lack of a secure high scores repository is hardly a big deal (although I’m often surprised when people tell me that they play wahoo.exe instead of sol.exe). However, imagine that a real application wanted to do the same thing. Maybe Microsoft only wants Office applications and not Linux knock-offs to query the clip art web service on microsoft.com. Or maybe your business wants to provide a web service that only your apps can talk to.

Of course, Microsoft doesn’t ship the source code for Word and your business is unlikely to ship the source code for your apps if you plan on making money on them (remember actually making money on software?), so that’s different than Wahoo!, isn’t it? No. Every time you put code on a machine outside of your sphere of influence, you might as well ship code, especially if it’s .NET code, which comes with a built-in disassembler! “But wait,” you say. “What about code obfuscators?” Well, that arms race has already been fought in the world of Java and disassemblers won. There was no way that an obfuscator can hide the details of Java byte code without completely destroying the usability of the code (particularly in the area of performance). .NET will be no different.

“Aha! But what about unmanaged code? x86 can’t be read like IL.” You’re right. It is harder to disassemble x86 than IL, but not significantly so. The x86 disassembler tool vendors have been working for a lot longer on this problem and we’ve bred guys like Andrew Shulman and Matt Peitrek that dream in x86 and only translate to English as a convenience for their wives.

The bottom line that if you ship code, you might as well ship the source, as it’s available anyway. If a computer can execute your code, somebody can read it and pull out the details of whatever you’re using to obfuscate the communication between your code and your back end (whether it’s a web service or not).

“So why do I have to log in all the time if there’s no such thing as security?” Well, it’s not as if there aren’t ways to secure systems in the world, but all working security thus far invented depends on physical security, whether it’s the private part of a key pair secured in your safe or a password secured in your brain. The reason that applications can’t make use of this kind of security is because they don’t have access to safes and their minds can be read much more easily that those of humans (although a rubber hose is just as effective as ildasm.exe, when something is really important).

So what does that mean for applications that want to make use of back-ends? I see four solutions. One, you can tie security to a user instead of an application. For example, if I make everyone sign up for a Wahoo! account to log high scores, I’d at least know who to ban from use when they faked impossibly high scores. However, it also opens up the possibility of the user completely bypassing the application altogether, including any checks that the client may make on validity of the data being sent to the back-end.

The second possibility is to make things hard*er* on the potential hackers. Keith summed it up nicely:

“After looking at your JPG, I’d suggest some server side filtering. Limits on user name length and content would help you at least reduce the amount of space that hackers can use for advertising. OTOH, you’ve got a nice little bulletin board going there ;-)”

Anything I do in the way of encryption and obfuscation between the app and the back-end will slow down potential hackers and for something like Wahoo!, I don’t suspect it would take much to keep folks honest (turning off the asmx test page would be a good first step, for example : ).

One way to make things harder, and a third way to secure apps, is a dongle, which adds new hardware to a machine along with the software. Unfortunately, a dongle could be reverse engineered just as a hunk of software. It’s only the fairly uncommon use of dongles that keeps them from being broken more often.

The fourth option, which Keith mentioned, is Microsoft’s new Palladium platform, which operates with special hardware and software to limit a user’s access to their own computer, kind of like a universal dongle.

The real question is, what’s secure enough? Unfortunately, this is an arms race that will eventually be won by any hacker with enough smarts, time and money. For users, we continue to make things harder on hackers as we transition from passwords to biometrics and smart cards. For applications, we’ve got dongles and precious little else, which makes it darn hard to treat apps like the independent entities into which they’re evolving.