The Abstract Truth

Archive for January, 2008

Its Not About Open Source

Posted by rbpasker on January 20, 2008

Another blogger is using my post “JBoss Should never have happened” to bolster their claim open source won the app server war.

What I wrote was that BEA was tied up in its existing expensive pricing structure, and JBoss was cheaper. Even the JBoss people themselves knew this: when JBoss raised money, I assisted one of the VCs with due diligence. I saw the JBoss investor powerpoint presentation. It was not about open source being better for customers. It was about a lower total cost of ownership.

I don’t believe (and never wrote) that the “innovator’s dilemma attack” by JBoss on BEA was a result of JBoss being an open source product. And, indeed, IBM’s WebSphere is not an open source product, and unlikely will ever become one. Neither is SAP’s NetWeaver or Oracle’s OAS. IBM bought Geronimo to prevent JBoss from doing to WebSphere what JBoss was doing to BEA: undercut its prices.

There is another aspect that pundits attribute only to open source, and that is frictionless adoption.

When we made our products available for a free download, all you had to do was click through an ELU and register. But there were a few things we could have done to make life more difficult and chose not to do:

  • We never changed the URL of the download page. If you had the URL, you could download the software without going through any hoops, and we never prevented anyone from downloading new versions.
  • You could type anything into the registration page. We never validated any of the fields. Lots of people put in junk, but plenty more filled the boxes in with correct info.
  • The license manager was easily defeated. We never tried to make it foolproof. People who wanted to hack it found it pretty easy to do, and we were flattered when instructions turned up on a warez site!
  • We never used an obfuscator. Paul Ambrose used to say that because of the decompilers, writing software in Java was like playing open-faced, naked poker. Some people sent in workarounds to bugs which were obviously made through decompilation. We didn’t care. We even had a joke about customers decompiling the software: “It looks like this guy used transcendental meditation to figure out what’s wrong.” (We did obfuscate some code which we had licensed.)
  • All the documentation and tutorials were online, and that was one of our best marketing tools! Even before they tried the product, prospective customers could read everything about it and decide for themselves. Some people using competitive implementations of standard APIs wrote to us to say how much they appreciated our putting the documentation and tutorials online!

Should we have become an open source product? Well, we did talk about it, and there were a few strong proponents in engineering. But at the time, open source enterprise software was still a few years out, and there didn’t seem to be a compelling reason.

When JBoss started to show up, BEA should have taken proactive (rather than dismissive) measures by lowering the TCO and making adoption frictionless again. They didn’t necessarily have to open source the product (although they could have); they just had to get rid of the cost and friction motivation for new adopters. Hindsight is almost always 20/20. I’m not sure what we at WebLogic, Inc., would have done under the same circumstances.

Posted in personal, startups, tech, work | 1 Comment »

Respect your Competitors

Posted by rbpasker on January 20, 2008

Some people have used my post “JBoss should never have happened” to gloat about the demise of BEA and the rise of JBoss.

I’m sorry, but that’s bullshit.

Rather than being paranoid at our competitors, Paul Ambrose kept in touch with them. He had good working relationships with Ofer Ben-Shachar and Zack Rinat of Net Dynamics. He knew Joe Chung of ATG, paved the way for alliances with Vignette, and always spoke in awe of the big deals that Kiva Software landed. He never said a bad word about anyone, and always made sure that our database drivers worked as well with competitors’ server products as it did with ours. As the market shifted towards our standards-compliant product (which was the template for J2EE), he championed discussions with competitors about licensing our core server code to them.

That is not to say that he was not fiercely competitive. But the energy he gave off was always positive, and he drove us all to compete fairly and squarely by building better products and winning deals. He never saw it as a zero-sum game, where the only way we could win is if everyone else lost.

So imagine my surprise when, one day in 1998, after we uprooted a competitor in a big account, one of the engineers who had worked on the project came to me and said something to the effect of, “this is another nail in their coffin. We’re going to kick their ass, and drive them out of business.”

I was floored! I knew the both CEO and CTO of the company, and they were good people. We had met at conferences and sat on panels together. I didn’t want them to go out of business, and I channeled Paul and told him that if he wanted to keep winning, to go back to his desk and fix some bugs.

More recently, I was shocked to read the blog of a guy whose company was recently bought, as he lay into his (admittedly combative) competitors. He wrote (I’m paraphrasing here): “To all my competitors who didn’t get bought: you’re in trouble because there’s nobody left to buy you. It must be scary for you if your exit strategy is acquisition.” (Many details purposely left out for obscurity)

Here’s what I wrote him in private email:

dude, please be a little more gracious. there are still a hundred or more people out there who have been working their asses off for years and will have little or nothing to show for it. if they pull your beard, so what? maybe they’re desperate. but there’s no reason to rub it in their faces.

He wrote me back:

I wish I could be more gracious. Unfortunately, my graciousness now gets translated by our competitors as an invitation to attack us, and when that affects the people that work for me, I feel like I have a choice other than to kick them sufficiently hard in the teeth so that they don’t do it again.

Five hours later, he wrote me back again, and said he’d taken the post down.


The proper way to demonstrate leadership to your employees is not to lash out at your competitors. Learn to be a good winner. Tell your employees to go back to work: write some code, get out in the field and win deals, think up a winning marketing strategy. By showing respect towards your competitors, your employees will respect you more, not less.

Posted in personal, startups, tech, work | 1 Comment »

The Impact of Culture on Innovation

Posted by rbpasker on January 18, 2008

Like most people, I suspect, how I feel about what I’m doing has a lot to do with the culture of the place I’m working. When I’m working with great people (or alone!) on an interesting project, I can be amazingly productive.

But in an environment where I feel undermined, or I am competing with other groups in my own company, or the company seems to be driven by raw power and power relationships, then I feel like I have no choice other than to bail.

This has happened a few times.

For example, when I was at Ingres in 1989, I worked in the Ingres/Net group, which was comprised of an eclectic group of 5 or so talented people who couldn’t get any of their ideas implemented because all of the decision-making power in engineering was held by the (also extremely talented) database server group and a few people in the front-end group who had been at Ingres for a long time. Ideas, no matter how good, that did not originate inside the power structure were summarily ignored. I don’t think any of the people in this powerful group thought there was anything wrong with the way things were. They just knew what they wanted to do and how they wanted it done, and everyone had to follow suit. I left after 9 months.

On the other hand, at WebLogic, we had a pretty good free flow of ideas. Over the course of 18 (very long) months, I single-handedly wrote most of GA server code that BEA bought (the database and html code was written by others, and we had a major release in the works at the time of the acquisition which had many contributors). The question I had to deal with as we started to hire people in January of 1997 was, how was I going to give all the new people coming on board a feeling of ownership over the server code.

Well, we had a bunch of things going for us:

  • a talented A-Team of new hires, who believed in the company and our mission of “Elevating Java to the Enterprise” [1], and were itching to get to work
  • I couldn’t continue to write code because I needed to hit the road and pitch customers. We were evangelizing a new category, and many of the sales people and Sales Engineers initially struggled with the presentation, although they all eventually became wildly successful at it

  • unlike a lot of one-person crash programming projects, the code base was in reasonably good shape
  • I had promulgated a hands-off testing framework, which was developed by BobA (who we lost many years ago in a swimming accident). This kind of testing framework is now institutionalized as “Continuous Integration,” and some of the WebLogic engineers later built and sold a company around this concept.

The result was that we had a very independent, yet cooperative, development team all working under one roof. People adopted or were assigned pieces of the system, like RMI, httpd, EJB, JMS, etc., and they worked on them independently. To provide consistency across the product, I instituted a set of “councils” on each subsystem, as well as on broad topics like security, management, and networking, that included me (as the chief architect) and a cross-section of 3 or so other members of the engineering team. Everyone in engineering was on at least one council, the monthly agendas and minutes were published, and anyone could come to any council meeting and contribute. I can’t say that every council functioned successfully, but what the councils did accomplish was to set a tone of of collaboration and the free flow of ideas across the engineering team. I didn’t need to make or approve every decision, and people learned to rely on their peers. That tone, I feel, spurred people on, because (unlike Ingres), people could get their ideas heard and incorporated across the product.

Following the acquisition by BEA, we faced something we had never experienced before: competition from the inside.

A week before the offer was announced, as part of the secret acquisition discussions, I went to a hotel conference room down the street with my laptop, and sat at one end of a long table filled with super-smart BEA technical people who were there to conduct technical due diligence. Eight hours later, I was flabbergasted. Nobody, except maybe one person, really knew what BEA was buying in WebLogic. They thought they were buying some sort of fancy web development system, like Cold Fusion, to act as a front-end to BEA’s leading product Tuxedo. Nothing I said in that room (“we have transactions, we have clustering, we have connection management, we have remote objects, we have message queueing, we have TP monitor underpinnings, etc.”) or showed them (I had my laptop open running Emacs on the source tree), would sway them.

This was quite a personal disappointment, because of all the possible acquirers (Sun, Netscape, Oracle, SAP, IBM, etc.), surely the BEA people would understand that what we had built was a Java-based TP Monitor. In fact, a group of us had gone up to IBM in ’97 to talk about WebLogic with the IBM software group, including Don Ferguson, the father of WebSphere. I have to say, the IBM folks really got it when we talked to them that day. Of course, we were dissapointed that they didn’t license WebLogic. Years later, I heard that IBM eventually spent a billion dollars to catch up with WebLogic.

Up until that point, BEA had been assembling a CORBA-based successor to Tuxedo, called “Iceburg”, first renamed “M3”, then, hilariously, renamed “WebLogic Enterprise.” M3 sold about 8 copies in total (I don’t have anything to back this number up, but I think its close to accurate!). The idea that a puke-y start-up from San Francisco with 20 developers could challenge the supreme legacy of Tuxedo was the rain shadow under which the acquisition took place.

At our first integration meeting, which included about 40 technical people from both companies, the topic for discussion was how were we going to turn WebLogic into a “web front-end” for Tuxedo. BEA’s Jolt Java client product for Tuxedo would be the lynchpin.

As you might imagine, I didn’t take well to this dicusssion. Having been one of the principal developers of a powerful TP monitor for VMS (which, after 20+ years, still powers the Citibank Funds Transfer Network and the Bank of New York’s Government Security Clearance System ), and having read the Tuxedo book, I knew what Tuxedo could do, and WebLogic was well on its way to being the web-based, OO successor to Tuxedo, TopEnd, and Encina. And I was right.

It was not only the technical people at BEA who were predisposed against WebLogic. Six months after the acquisition, I went to a strategy meeting at a Very Large Manufacturing Company, with a large group of BEA sales executives and technologists, and the local former WebLogic sales rep. In the pre-meeting meeting, it was predetermined that we were there to sell them M3 because they were a CORBA shop. Never mind that WebLogic had had many customers using CORBA successfully with our server product; the corporate mandate was sell M3, and no one in the room wanted to hear anything else.

I figured that if I was going to stay at BEA as Chief Architect of WebLogic, I would have to continue to deal with these kinds of issues. But endless political fights with closed-minded people was never my strong point (to say the least). I had to find something else to do.

WebLogic had had very good success selling WebLogic to ISVs as the underpinnings for eCommerce and content management products such as Moai, Vignette, and e.Piphany. But we decided that we were not going to compete in those markets because it would make it more difficult to acquire new ISVs, a major indirect channel for us.

At BEA, however, there was no such compunction. In early 1999, I lobbied to head up a new group that would accelerate the development of “verti-zontal” applications, that is, vertical apps that could be applied across many different industry sectors, such as a portal and eCommerce and content management systems. It took another month of lobbying to get even 2 developers. We all moved into one office. We started whiteboarding.

Then the calls started.

The rumor had gotten around about what the Vertizontal group was trying to do, and I got phone calls and visits from engineers, managers, directors and VPs from San Jose, Texas, and New England, who were tasked with building the exact same thing! Four separate groups, in 4 separate states, from 4 separate acquired entities, all within one mid-cap company, were now in competition. We were all starved for resources, we all had different ideas about what we wanted to do, and we all reported into different parts of the organization.

I attempted, obviously unsuccessfully, to get everyone working together, but the politics took over. Who would be in charge? Who would lose headcount to this group? What would be the underlying platform? What would happen to the managers and directors who were no longer needed by this consolidated group?

In the end, I don’t know what happened to the other 3 groups. I left.

BEA eventually built a portal product and acquired another one, and an early opportunity to build a suite of now-indispensable products on top of WebLogic evaporated.

Posted in startups, tech, work | 4 Comments »

JBoss (and possibly TomCat) should never have happened.

Posted by rbpasker on January 17, 2008

BEA made a lot of mistakes. Letting JBoss out of the box was probably its biggest.

While BEA was looking “up” at its biggest competitor IBM, JBoss was busily undercutting BEA at the bottom end.

The old mantra for enterprise software companies was that in order to have high gross margins, the labor-intensive services part of the business had to remain well below 40% of revenue. And since middleware was so critical to the F500, license costs had to be suitably high. BEA’s business was tied big deals at $10K/cpu.

JBoss launched an innovators dilemma attack against BEA, not with a revolutionary product, but with a revolutionary business model, one that BEA couldn’t hope to copy without cannibalizing its existing revenue stream. BEA fell right into the trap.

Also, at the time WebLogic, Inc., was acquired we had two server offerings, which became known as WebLogic Server and WebLogic Express. They were in fact identical code bases, but the “Express” product was a Servlet engine with JDBC, and no clustering, EJB, or other fancy stuff. It cost about $2500.

The great thing about this product was that if you were building a web-based application, you could get on board cheaply. This product was effectively killed off because BEA (and the sales team) didn’t think a billion dollar company could have $2500 product, especially when they could sell a $10K/cpu product wrapped inside a 6- or 7-figure deal. Enter JBoss, with its low price of adoption, and a 2-horse race became a 3-horse one.

In February 2003, BEA finally had to backtrack, and reintroduce the Express product.. A month later, they lowered the price from $695 to $495, a silly move in a market that is not price sensitive at that cost. Unfortunately, it was already too late.

Please read this update.

[Its also interesting to note that C|Net erroneously called this a “introduction,” not a re-introduction, and that it was in response to IBM’s “express” product.]

Posted in startups, tech, work | 5 Comments »

Oracle (ORCL) to Acquire BEA Systems (BEAS)

Posted by rbpasker on January 16, 2008

While the west coast sleeps, the east coast filled my inbox this morning with the news.

I have two initial reactions:

1. I hope the WebLogic brand survives, rather than being folded into Fusion. “WebLogic” has always been well recognized as an excellent product and a pioneering product in the application server space , and “BEA” has little cachet, unless your name starts with B, E, or A.

2. Arrogance is as arrogance does. Carl Icahn, well done.

Much has happened in 12.5 years since we started WebLogic, Inc. and in the 9 years since WebLogic was acquired by BEA Systems, and I need to think more about what I want to say.

Posted in startups, tech, work | 1 Comment »

Flying Car For Sale on eBay

Posted by rbpasker on January 12, 2008

Another flying car-type vehicle that came and went. From reading the comments and Q&A (not to mention the number of hits I get on my blog), there is a tremendous amount of interest in these vehicles!

The last Concept Sky Commuter aircraft in Existence

Posted in flying | 1 Comment »

Back to Basics

Posted by rbpasker on January 5, 2008

I’m testing an unreleased web service which requires mod_python. Because mod_python comes as source, I had to build it for OS X 10.5.

Of course, configure failed miserably with the brilliant:

checking for C compiler default output file name... configure: error: C compiler cannot create executables

Searching the web for how to fix configure problems, I found a suggestion to compile something simple, to see if gcc is installed correctly:

% cat test.c
#include <studio.h>

int main (int argc, char* argv[]) {
printf("hello world\n");
return 0;
% gcc test.c

This also failed.

I figured that since I hadn’t done any development on this machine since 2004 or so, it was time to reinstall Apple’s Xcode.

Once I reinstalled Xcode, test.c compiled perfectly, and configure ran without a hitch.

After 30+ years of programming, the same techniques still work: get the simplest possible thing to break, then fix that.

Posted in tech | Leave a Comment »

How to Screw Up a Product Testing Cycle

Posted by rbpasker on January 2, 2008

Dear Product Manager,

Thanks for sending me your product! One of the most rewarding things I get to do in my professional life is get an early look at new products, and because I consider these early looks a privilege, I promise to reciprocate to you by providing quality feedback as quickly as possibly.

I know that your product may be raw, and might lack the stability, richness, or completeness that the ultimate product will have. I won’t ding you or your product for features or stability you didn’t promise me!

And thanks for setting up an email responder and forums and bugtrackers and mailing lists to collect feedback. And I’m glad your management identified you as the point man for this testing cycle. Both of these are very important.

Nevertheless, because our interaction during this testing cycle has been so poor, I have filed your product in the Bit Bucket, and I won’t be sending you any more feedback.

Here are some of the most common reasons:

  • You didn’t read my email / forum post / bug report. I told you that I read all the FAQs and docs, and I even gave you a list of things I tried. Why, when you responded, did you send me a link to another FAQ or doc page, or ask me if i tried this or that? Don’t send me a canned or ill-thought out response. I did my half of the job, now do yours: read my email.

  • You didn’t get me to the point where I could really try your product. When I sent you that note that said, “I’m still stuck on step 2 of the install,” I put your product aside, waiting for a response. Its took you 6 days to get back to me! Now I have to swap the whole mess back into my brain’s working set, and start over. You should have sent me the missing file, answered that one question, or fixed that little bug, so I could at least try your product out.

  • You didn’t test your product yourself before sending it to me. Yes, I know it works for you, but I have a “customer” environment. The URLs are hardcoded to point to a server behind your firewall. You’re referencing a file in your source code repository. You should have taken home a pristine laptop, and tried it yourself before sending it to me.

  • Your product has platform or version dependencies, but you didn’t try my configuration before you sent it to me, or you didn’t ask me if my configuration matches what your product requires.

  • You said you would send me a fix, but you didn’t. I’ve waited a week. I can see the bug in Bugtraq. How much longer do I need to wait?

  • You sent me a new release, but you didn’t mention the showstopper bug I reported. Is it fixed, but you didn’t add it to the release notes? Has it been forgotten? Is it in the queue?

    Hopefully, you get the point by now: when you’re in the role of testing program manager, you have to keep us testers productive and informed! If you do, we’ll work hard for you, and help you make a better product.

    Best, bob

  • Posted in startups, tech, work | 2 Comments »

    %d bloggers like this: