The Abstract Truth

  • Get the Album

  • Archive for the 'tech' Category


    Fountain: a fully-featured “Google App Engine”

    Posted by rbpasker on April 8, 2008

    A month ago, I put together the following slides for a new service, which I called “Fountain.” It has similarities to Google App Engine in that it is a scalable, hosted system for running back-end apps, but Fountain has a number of unique features, which perhaps we’ll eventually see in GAE.

    Among these additional features are:

    • support for languages beyond Python, including server-side Javascript using Rhino (which we first saw circa 1995 in Netscape SuiteSpot), PHP, and Ruby.
    • A Business Management Workbench, for monetizing the apps. I am keeping this under wraps, as I may still choose to develop it.
    • Social Networking support, which includes all the libraries necessary to write social networking and widget apps, such as for OpenSocial, Facebook, PageFlakes, NetVibes, iGoogle, etc.
    • a community, so that people can share code and pre-built libraries with others. One could argue that Google Code provides this functionality, but it is not yet tightly integrated.

    So, here are the slides. Feedback is appreciated.

    Posted in tech | 1 Comment »

    Hello, New York Times!

    Posted by rbpasker on March 25, 2008

    In Goodbye, New York Times, Jimmy Guterman writes that he is no longer going to read The Times in hardcopy. I can appreciate that. Its expensive (relative to the online version), wasteful (pace recycling), and gets your fingers dirty.

    But instead of looking forward to why The Times hasn’t joined up with Amazon to deliver the news on Kindle, or with Apple to produce an offline iPhone/iTouch news reader, this O’Reilly writer, ostensibly a leader in new media, shows himself to be stuck in the last century’s thinking about the newspaper business.

    First of all, Guterman writes:

    For all the pleasure of holding and print, the Times on paper is just too late. In 2008, today’s paper is yesterday’s news.

    The reason people read the New York Times is not for the late breaking news, but rather for its news analysis, which has expanded in recent years. Years ago, The Times realized that it had stiff competition from the web and cable news, especially on the west coast, when deadlines are 3 hours later. New analysis, however, is reflective, and competes on insight rather than timeliness. By Guterman’s logic, print weekly and monthly news magazines would also be worthless.

    Guterman also writes:

    In this era of advertising-is-the-only-business-model, management at the Times Company has decided that I’ve decided that the value of what it sends to me is zero.

    Actually, The Times Company has decided that the value of what it sends him is quite high, but the paywall revenue was growing much slower than the advertising supported revenue.

    “The business model for advertising revenue, versus subscriber revenue, is so much more attractive,” he said. “The hybrid model has some potential, but in the long run, the advertising side will dominate.”

    I’m not saying everyone has to read The Times in print. I certainly scan the Times’ RSS feed for headlines once during the day. But if you’re going to dump the print version, its should be because of cost, wastefulness, and cleanliness. A hardcopy paper won’t easily be able to keep up with the web, but the print version (or a physical facsimile thereof, like the Kindle or iPhone), read in repose, is more conducive to thoughtful reflection and analysis than sitting at ones desk flipping through links.

    Posted in tech | 2 Comments »

    How to Write Crappy Documentation

    Posted by rbpasker on March 10, 2008

    Dear Documentation Author:

    Thank for putting out a 150 page document on your new product. I really appreciate it when a company puts the time and effort into producing a voluminous manual, rather than just letting people figure it out for themselves.

    But I would have to say, your documentation is worse than useless.

    Here is a perfect example:

    docs.png

    It is not OK to show a screenshot of a dialog box and then just list the elements in the dialog box and tell me to fill it in!

    You also don’t need to tell me how to mark a checkbox, “Click next” or “Click Finish”.

    I do in fact know how to read the screen, and I do in fact know how to use a mouse and keyboard to move around the screen and fill in boxes.

    What I don’t know and can’t tell from your documentation, is the definition and usage of concepts and terms in the dialog box, such as “Server Path Mapping”, “Platform Server”, and “Platform GUI”. Please either inline or hyperlink descriptions of what they are, and tell me how your application uses this information. I don’t need to know how to go about “Defining a Platform Server”. I need to know what a “Platform Server” is.

    Furthermore, you documentation implicitly asks me questions (’Do I want platform integration?’, “Do I want ‘tunneling’?”), without giving me any clue about how to make a decision or what the impact is of my decision.

    It seems that some of the information on the form – URL, return host, server root, username and password – needs to be coordinated with other applications. It would be useful to know exactly where this information comes from, and how its used here.

    I’m also concerned about putting a password into the dialog box. Is it stored in plain text? What are the permissions on the file in which they’re stored?

    And please don’t tell me to “enter the relevant information.” If I knew the “relevant information,” I wouldn’t be reading the documentation. Its your job to tell me what the relevant information is, where it comes from, and how its used in the application.

    I wish that the above was an isolated incident. But in fact, this may be one of the more informative sections of your manual.

    The point of documentation is to inform and educate, not to explain how to move around the screen and how to fill in the blanks.

    I’m sorry, but your manual just doesn’t cut it.

    And its worse than useless because I spent way too much time hunting around for information in your manual, and not enough time getting done what I wanted to do.

    Sincerely,
    A former user

    Posted in tech | No Comments »

    iPhone Application Ideas

    Posted by rbpasker on March 9, 2008

    With the introduction of the iPhone SDK, people will be writing iPhone apps like crazy. There are a number of special features in the iPhone that make it the perfect platform for advanced mobile applications, so I’ve started brainstorming about what some of these apps might be.

    There are three new technology features in the iPhone that I think will make the biggest difference in the kinds of applications people can build:

    3D Accelerometers

    With previous mobile devices — such as Blackberrys, Window Mobile, and Palm — users interacted with the device via the keyboard, stylus, or scrollwheel.

    Using the iPhone’s 3D accelerometers, the iPhone can sense its own orientation to the earth in 3 axis and measure how fast and in what direction the iPhone is moved.

    With orientation and motion detection, users will be able interact with the device by holding or moving the iPhone in a certain way. For example, when using the iPhone’s phone function, dialing and holding the phone up to one’s ear disables the touchscreen, so that the user’s cheek doesn’t accidently interact with the screen. When the user moves the phone away from his ear, the screen is again enabled.

    Continuous geographic location reporting

    Even without a built-in GPS, the iPhone can approximate its geographic position by using radio waves to measure its distance to surrounding cell towers. This position reporting is accurate to within a few hundred yards, and is much less accurate then GPS, which is accurate to a dozens of feet.

    Using the location services, applications can change their behavior depending on where in the world they are.

    The most obvious use for this feature is for location-based services, such as maps and driving directions. But location services could also for new kinds of commerce, such as distributing discount shopping coupons to consumers who are near a particular store.

    Bonjour networking

    This is the unsung hero of the iPhone. This technology lets Bonjour-enabled devices interact with other Bonjour-enabled devices in the immediate area without requiring a central server. Now, two iPhones can communicate with each other directly, so long as they were within WiFi range.

    This feature would allow friends or family members to find each other in a crowded mall or movie theater, or send each other files and media without using email or SMS.

    Other Bonjour-enabled devices include printers and webservers, so iPhones would be able to print on local printers without configuration, or browser the websites of local merchants.

    New Application Designs

    Rather than putting my application ideas up here on my blog, I am hosting them on Google Sites because I want to be able to add new ones and improve them. I’m Putting each application in a separate blog post so people can comment on them individually.

    Posted in tech | 5 Comments »

    iPhone Ideas — RideReporter

    Posted by rbpasker on March 9, 2008

    Posted in tech | No Comments »

    iPhone Ideas — BizCardSwapper

    Posted by rbpasker on March 9, 2008

    Posted in tech | No Comments »

    iPhone Ideas — FrienDar

    Posted by rbpasker on March 9, 2008

    Posted in tech | 1 Comment »

    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.

    Bravo.

    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 »