Archive for the ‘startups’ Category
Posted by rbpasker on September 18, 2010
Posted by rbpasker on May 21, 2010
Virtualization is Big.
Not only does it encompass what we traditionally think of virtualization: running multiple guest OSes on the same piece of hardware, but it also is the enabling technology for other large initiatives, such as server consolidation, data center continuity, virtual desktops, cloud computing, and “infrastructure as a service.”
The dirty little secret is that virtualization places a huge burden on storage systems. VMWare has a suite of products, a team, and a blog all dedicated to storage issues.
And Azure Capital Partners, where I am the CTO-in-Residence, recently co-led the Series A investment in CORAID, a leading storage networking company for virtualized environments. CORAID’s EtherDrive product provides a 5-8X cost reduction over legacy storage systems with its “scale-out SAN architecture that is ideally suited to dynamic virtualization and cloud environments.”
But the virtualization storage problem is multi-faceted and complex, so the breadth of solutions must be equal to the task.
This is why I am pleased to announce my participation, along with Bipul Sinha of Blumberg Capital, in a seed round at Nutanix, an enterprise-class storage management company led by three world-class entrepreneurs Dheeraj Pandey CEO, Ajeet Singh COO, and Mohit Aron CTO.
Nutanix is still in stealth mode, but they do have a hint on their career page:
Nutanix is a stealth-mode startup building a disruptive product that is designed ground-up to leverage trends in virtualization, solid state drives, and cloud computing, each of which plays a very critical role in reducing cost and management complexity, improving performance, and providing revolutionary data management capabilities to the enterprise.
Keep an eye out for Nutanix. Big things are happening.
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 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 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” , 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.
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.
[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 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 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:
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.
Posted by rbpasker on September 6, 2007
Posted by rbpasker on August 30, 2007
A week or so ago, I wrote about Bug Labs new personal hardware development platform. Today they put up details about the platform, descriptions of the first few modules, and screenshots of the Eclipse IDE support.
Lets look at the BUGBase:
- ARM processor
- 128MB RAM
- Button controls
- 1x USB 2.0
- 4x serial ports (hopefully 230K)
- Hardware MPEg-4 codec
- Hardware graphics (no spec)
Its unclear how much non-volatile memory the device will have, but it will need at least a gig or two, preferably on high-speed removable media. I’m also hoping the device will have power-management capabilities coupled with sub-microsecond hardware timers.
The base will be available around the same time as the first four modules:
- Digital Camera / Videocam
- Touch-sensitive, Color LCD Screen
- Accelerometer, Motion Sensor
The accelerometer is pretty cool, but I probably wouldn’t use up a slot for it, because in Q1 08 I’ll add one these modules:
- Touch-sensitive, Color LCD – 2X
- Mini-QWERTY Keyboard
- Audio Speaker, Input/Output Mini Jacks
The teleporter has me confused. Being as small as it is, this teleporter will probably use old 60s-era Star Trek technology, rather than something newer, like the an X-Men-based mutation field. But still, the benefits of being able to get around instantaneously will outweight the fashion drawbacks of the 60s.
If you’re listening, Bug Labs, here’s my laundry list of modules for Q2 08 and beyond:
- phone, including SMS/MMS, and 3G networking
- a software radio for AM/FM/XM/Serius reception
- TOSLink 5.1 audio for surround-sound A/V
- IR transmitter/receiver for making a universal remote
I think my full-fledged all-in-1 PDA/iPod/Camera replacement will need 6 modules: GPS, cam, LCD, kbd, audio, and phone. Since the device only holds 4 at a time, I’m hoping the modules will be hot-swappable.
My first project will be a fully integrated, internet-aware, extensible PDA. I’ve already started thinking about the internal architecture for such a thing that would allow people to develop their own web-services aware PDA plug-ins.
Well, I’ve applied for the Bug Labs beta program. Let’s hope they have room for me!