Help
Over the last few months, the BBO development team has been doing a remarkable job making enhancements to this site. In particular, the addition of pair’s tournaments has been a very welcome development. [I’ve certainly enjoyed the alpha-test tournaments that I have participated in]. Its really been amazing watching the growth in the membership.
However, as these new features and functions are added, I will once more make a plea that the development team devote resources to implementing a set of standardized interfaces within the BBO software. Currently, the BBO software looks and feels very much like an integrated “product”. I believe that everyone’s interests would be better served if the development model focused on a “platform leadership” strategy. [For anyone unfamiliar with the expression, “Platform Leader” is the titled of a book by Annabelle Gawer and Michael Cusumano. The book proposed that many high tech companies have succeed by developing standardized platforms that they then use to promote the sale of complementary goods. As a concrete example, Intel has taken an extremely active position in promoting PC bus architectures, even though it does not make revenue from this standard. Rather, the company recognizes that a standardized bus architecture is promotes the sale of the microprocessors that are Intel’s bread and butter]
Over the past few months, it struck me that there is an extremely interesting parallel between Intel’s revenue plan and some of the strategies that Fred is following with Bridge Base Online. In particular, Fred is not trying to use BBO as a direct source of revenue; rather this service is intended as a tool to promote the sale of a variety of software products. While I am extremely satisfied with the BBO software (can’t find better at twice the price), I do think that an alternative product development strategy focused on standardized interfaces would yield a number of important benefits.
Before progressing any further, I’d like to provide a concrete example to ensure that everyone is on the same page so to speak. As most people know, the BBO software has a rudimentary convention card utility built into it. This utility incorporates a number of functions including:
(a) An editor used to define new convention cards
(
A distribution system used to transfer a convention card from one user’s computer to another© A viewer used to display a player’s convention card
Eventually, it will be necessary to upgrade the convention card utility. I argue that the best way to do so would be to link the BBO application to standard web browsers. Players would use their “standard” Netscape or IE or Opera web browser to render an HTML compatible convention card. The convention card editor would be removed from the BBO application. While this functionality is obviously still necessary, it can [and should] be provided by a separate application.
There are a number of advantages to this scheme. First, while some upfront development work would obviously be required, in the long run this type of system will minimize the amount of development work required by the BBO team. Under this plan, the BBO software only needs to provide one core function: The BBO application still needs to upload a convention card and transmit this to the PC used by the opposing pair; however, there is no longer any need to directly support the viewer or the editor. [This analysis pre-supposes that a third party development community is willing and able to provide an application that can be used to create HTML convention cards. Big if, I realize, however, this isn’t an especially difficult programming task. I’m quite certain that I could get a group of friends to volunteer enough time to release a user friendly editor suitable for non-technical users]
The second equally important advantage is that players now have the option to flexibly extend the default convention cards. For example, I’ve been playing around for quite some time trying to define an appropriate HTML convention card for MOSCITO. My card, which is available at http://web.mit.edu/~...www/MOSCITO.htm is much more complex that I would expect a regular pair to deploy, let alone a pickup partnership. However, players with long standing partnerships might chose to develop such a card and should have the ability to do so.
Returning back to the more generic concept of Platform leadership, I strongly advocate that the development team work to standardize interfaces between “parts” of the BBO Software. Furthermore, the interfaces should be published openly so that third party developers have the opportunity to contribute to this project. Ultimately, I would hope that Fred, Uday, and the rest of the team will be able to publish the interface standard between the BBO client and the server. This would allow players to use any client that they wanted to communicate with the BBO server. In the short term, however, I think that there are a number of existing functions that can be opened up. In addition to the convention card example that I already described, I would dearly love to be able to export deals from a third party deal generator such as Hans van Staverns’ Dealer into the BBO training rooms. The training rooms are a wonderful idea and well implemented, however, BBO’s deal generator will never match the power or flexibility of a specialized application.
As I mentioned, I think that migrating to this type of development model would really be a win-win situation.
Ideally, this type of scheme will substantially decrease the amount of resources that Fred and the rest of the BBO team need to spend on software development. There is a frightening overlap between bridge players and computer professionals. Over the years, I have seen an enormous number of software development projects focused on bridge utilities. Some of these projects have evolved into commercial products [OKBridge started as a hobbyist effort. OKScript is another good example] However, may more projects produced remarkable sophisticated freeware applications. Dealer may be the best example of this type of effort. Portable Bridge Notation was another interest development project. Standardizing the interfaces for BBO [potentially even releasing the client as Open Source Software] could easily create a development locus for bridge related software.