Sunday, April 29, 2007

Voting, Software and (In)competence

There's an interesting article in Wired regarding voting issues with electronic voting machines in Ohio. It's been very interesting to me to watch over the past few years the number of people who have spoken of rigged votes, stolen elections and conspiracies with our elections system. What started in Florida with hanging chads was supposed to culminate in mistake-free elections with the introduction of "modern" technology.

I don't believe that any votes were stolen, any elections went the "wrong" way or that there's a widespread conspiracy in the elections system. I believe there's a much simpler explanation - sheer incompetence. I also believe there's a much simpler solution - open-source.

One of the most troubling points in the article was the claim that Diebold, the voting machine manufacturer, was claiming proprietary trade-secrets regarding the voting machine software, database design and data. I can't quite tell from the article if this was an actual claim or an assumption on the part of the auditor. Either way, this is extraordinarily troubling to me.

Voting is something that we should all take seriously in an almost sacrosanct way. Whatever your political beliefs, or lack thereof, voting is your most fundamental way of expressing your political beliefs.

That anyone, a manufacturer or a consumer of voting machines could believe that there's proprietary secret-sauce within the machine is shameful. The way that machine works must be transparent. Otherwise, there will be no faith left in the elections system at all. Transparency breeds trust, opaqueness breeds fear and distrust.

No elections commission in this country should give away their rights to fully understand the inner workings of any machinery related to the voting process; including the software.

My biggest fear is not that a conspiracy will steal elections - that takes too much coordination and too much secrecy. My fear is rooted in the many software systems I've seen and the possibility, or even the probability, that someone will make a moronic/crappy/idiotic decision in either the design or implentation of the system.

If Cuyahoga County in Ohio wants a true audit of their elections process then they'll demand to have a look at the source code.

Open-source is not just a fight against closed-source vendors. It's not just a new business model. Open-source is something that gives us back the transparency we demand in our government. Leaving our destiny to the magic of mysterious tabulating machines is not how I want our votes counted and you shouldn't either.

Saturday, April 28, 2007

More customer service...

This time with a bank. I have a document from my bank in front of me with an incorrect address for me.

Being the helpful soul that I try to be, I call the bank's service number and try to help them with their data accuracy. Their response was interesting, after answering many questions to prove who I am, they tell me that they will need the request in writing because the account is less than a year old.

I'm just flabbergasted. If I want to steal my own identity I'd happily send them a document in writing. The issue is that their data-input person typed the wrong address and I'm being asked to write them a letter to help correct it.

Brilliantly, I reply, "You already have it in writing. The original form I filled out and signed has the correct address on it, look it up and correct your problem."

I'm often met with silence when I engage others in conversation. I'm used to it and have become quite comfortable with silence. I don't feel compelled to fill the room with words just because no-one can think of something to say.

This silence went on for a while, though, and I was wondering if I had been disconnected. But I held on and waited.

Finally, the customer service rep came back and said, "Yes, we'll need that in writing. Just write a letter telling us the correct information and we'll correct it."

We repeated this exchange the obligatory three times before he either gave up or actually realized what I was saying. He corrected the address in their system and now everyone's happy.

Customer service, sheesh, that means service to the customer, not from.

Friday, April 27, 2007

Dealing With Customer Service

I'm in Scottsdale right now. My server is still back in California. In the middle of copying files this morning I lost my VPN link back to my home server. What an immense drag. I'm 750 miles away. The last time this happened I had to wait until I could get home to solve the issue.

The first step I performed in troubleshooting was to connect to my router at home. Un-surprisingly, it wasn't available. This was relatively good news, it meant it was a network issue and not a server issue. The next question, do I call home to California at 6:00 am to tell my wife the network's down or do I just wait until later in the day. My wife is home entertaining her mother and two of her aunts while I carefully look after things in Scottsdale. I'm sure she doesn't want a pro-active call at that time of day so I put it off 'till later.

Of course, I get a call from my wife later in the day asking why her Mac can't connect to the network. As if by magic I explain to her that the network is down and step her through the process of checking things out. Sure enough, Pacbell/SBC/AT&T has, once again, failed in their delivery of DSL services to my home. This is about the 20th time it's gone out in the past 7 years; at least, as far as I'm aware.

While I was having my wife get ready to power-cycle the DSL modem it re-synced and came back up. I'm back to copying my files and life goes on. But then my wife asked what we would have done had it not mysteriously re-appeared.

"That's easy," I replied, "we would have called Pacbell/SBC/AT&T customer service."
"Oh, what a pain that would be," she replied.

Then I explained how to deal with customer service. Given the number of times this has happened I know the routine and I know that it is likely that they will continue their 100% streak of it being their fault. I humor customer service. As they ask me to check things I merrily bang away at the keyboard and reply, "Oooooh, that didn't work, what should I try now." Of course, I'm not actually doing anything. I know the issue is on their end but they won't escalate and accept responsibility until they have me try everything.

So, I bang away, saying, "Yep, tried that and it still doesn't work." Eventually, they say it must be a network issue, they create an internal trouble ticket and I get service back typically by the next morning.

I've tried bypassing this process many times but I always get the same answer, "Sorry, but we need to check everything."

Of course, it's entirely possible that they're on the other end making things up for me to try just so they can appear to be "helpful." What a sad state of affairs customer service has become.

Thursday, April 26, 2007


Wow - it's been a long time since my last entry on April 2nd, time is just flying by. I do have a couple of things built up that I need to get out.

I received a comment recently asking about analysts and their lack of bullishness on open-source projects. I think that we need to really understand the role of the typical analyst vs. the role of the futurist. I wrote a blog entry just over a year ago, titled "Stan, The World's Greatest Futurist, that explores predicting the future. The futurist has a very different job from that of the analyst.

The job of an analyst, to me, is to help explain, via thoughtful study (analysis) why something happened or what something that just happened means. For example, why did a company announce only $0.01/share of earnings when $0.25/share was expected? Financial analysts should be able to help us understand why this may have happened. Technology analysts should be able to tell us why some technologies are successful in a specific market.

Analysts use their life-experiences to help them understand why certain events occur.

Where we, as an industry, often get in trouble is when we expect the analysts to predict the future. More specifically, we get in the most trouble when we ask the analysts to predict the next major waves within an industry. Personally, I think many of the analysts with whom I've worked have had difficulty predicting the past, but that's another point.

I truly believe that it is exceedingly difficult to use one's analytical skills and past experiences to predict new waves and new technologies. New things come from out-of-the-box thinking; they don't come from tried-and-true methods.

It's a huge stretch to assume that a mainstream analyst who has spent their career analyzing proprietary software companies, and understanding how those companies value their closed-source technologies as intellectual property, is going to easily transform into someone who understands the benefits of open-source.

These analysts think that software companies only exist because they have proprietary, closed-source, secret sauce ingredients that would be too expensive for anyone else to copy. Therefore, an open-source company can't possibly succeed as a software company.

Perhaps the real issue we have is that we should stop calling open-source companies software companies. Maybe it's our own fault for using obsolete terms to try and get others to understand what we're all about.

Anyway, back to analysts and Stan - there's a huge difference between explaining the past and predicting the future. Although, I predict that I'll get a fair amount of complaints from the analysts in the audience. Wait, that's already happened - am I an analyst or a futurist.

Monday, April 2, 2007


I was reading Groklaw earlier today and came across an entry that brought back a lot of memories. This particular entry itemizes the relationships that SCO had and that they accuse IBM of interfering with and damaging.

At the time that SCO launched their lawsuit against IBM I was in the midst of managing Oracle's Linux Program Office and I had responsibility for Oracle's relationships with all the Linux players. We had a pretty good relationship with SCO mainly because of the work that was going on with Project Monterey, United Linux and others.

The relationship between SCO and Oracle was pretty much doomed once SCO filed their lawsuit. Contracts are interesting devices. In my mind, contracts serve two purposes - to chronicle the agreement for the future, that is, to serve as an aid for those not involved in the original negotiations so they know what was intended and as a means of enforcement once the relationship is dead.

If a relationship gets to the point that a court is needed to enforce the agreement then there is, arguably, no longer a relationship. If you don't think you need to chronicle the agreement for future generations to abide and you'll never sue the other party, then you probably don't need a contract. A lawsuit is the ultimate way of saying that one no longer cares about the relationship and the terms of the contract are more important than the relationship itself. After all, if the relationship was more important than the terms of an individual contract then there would be no lawsuit to enforce those terms.

At the time of the original lawsuit, SCO was out there trashing anything and everything associated with Linux saying that everyone was, essentially, stealing from them. They filed a number of lawsuits against a lot of companies.

The question I asked at Oracle was, "Why would anyone want to do business with them?" It was clear to me that for SCO, the terms of their contracts were more important than any relationship that led to those terms. I wasn't about to propose entering into any contracts with SCO. From my perspective they were not a company with which I wanted any kind of relationship.

When I joined Ingres one of the first voice mails I received was from SCO wanting to enter into a relationship with us. I wasn't the only one who received the calls. My advice was to ignore the calls - don't even return them. If SCO was asked I'd rather they would have to answer that they left us voice mails rather than they were in any type of discussions with us, even if those discussions would ultimately be fruitless.

The other interesting item in the Groklaw post was the identification of the "Chicago 7" as another group with whom SCO had a damaged relationship. I never really paid any attention to the Chicago 7 thinking it was a 1960's radical group of some type that I missed out on. As it turns out, the Chicago 7 is a label used for a meeting of a group of people at the Chicago O'Hare airport back in July of 2003. I was one of the "7" at that meeting. Darl McBride spoke about the "Chicago 7" as if it was some type of conspiracy against SCO.

Honestly, the only things I really remember saying about SCO in those days came from a very short list:

"What a bunch of idiots."
"What a bunch of morons."
"What are they thinking?"

Experiences are important - they help us learn and grow. The folks at SCO have a hell of an opportunity to grow. But, then again, my sayings about SCO from 2003 probably still hold true. I won't miss them when they're relegated to the ash-bin of history and are just a faint memory.

Busy, busy, busy...

I've been a bit busy lately. Wendy and I have a new place in Scottsdale that we've been enjoying. Actually, I've been enjoying it a little more than Wendy as there are six golf courses. I've only been able to play four of them so far but it has been an enjoyable few weeks. Now that I have internet set up and a computer here I can spend a few minutes getting back to some reality.

Oracle has, as expected, announced a number of new customers for their Linux support offering. This is no surprise and I expect that Oracle will ultimately gain a fairly large number of customers using their services. I'm not sure I would be one of them but it's simply the law of large numbers, some set of companies will sign with Oracle.

I've seen a lot of speculation in the press about why Oracle behaves the way it does with questions about their underlying motivation. It's very simple - Oracle is a proprietary software company and they want to protect their intellectual property and their customer base. Oracle will go after anything that threatens that install base. They will attempt to do so in the most efficient manner possible. This is called capitalism. There's absolutely nothing evil or wrong with this strategy. It's the same thing many of us do when we negotiate our salaries for new jobs or the price of the car we're going to buy.

The danger to Oracle in the long-term has to do with their attempt to lock-in a monetization model for their market. History is filled with companies that failed to see future movements within their industries and, ultimately, failed themselves. This strategy is borne of having something to lose. Oracle has a lot to lose and, therefore, faces more risk than smaller companies.

Start-ups, on the other hand, have nothing to lose and everything to gain. It's the new ideas that are the most threatening to large companies. I think of the start-ups as thousands of innovation engines, any one of which has the capacity and capability to re-define markets. While the risk for any individual start-up is tremendously high, the risk to all startups is rather modest. That same law of large numbers will virtually guarantee that some new company with some new idea will not only succeed but will thrive in the market.

Oracle's strategy is to avoid, alter or subsume the new ideas that arise from these start-ups before they become full-fledged threats. Long ago, Oracle and Microsoft were the up-start new kids on the block with revolutionary ideas that challenged the status-quo. Who are today's up-starts that will have our attention and respect 20 years from now?