Dan Baigent's Weblog: The ravings of a lunatic

I joined Sun in February of 1997 as JavaSoft's first Systems Engineer. We eventually grew the organization to well over 50 SEs world wide and I managed the Western Region (including Western US, Canada and all of South and Central America). Throughout the late 90's, I managed the technical support organization that helped negotiate and close Java Technology licenses in this region, including major J2EE licenses and J2ME licensees.

In August of 2000, I joined Jonathan Schwartz' new Corporate Planning and Strategy group as a Technical Portfolio Manager. For a little over two and a half years, I managed Sun's relationship with companies in which Sun made an equity investment. I also helped Sun develop strategies for strategic acquisitions and new equity investments.

In January of 2003, I joined Curtis Sasaki's newly formed Desktop Solutions Engineering group as a Director of Engineering working on Sun's first true desktop product, the Sun Java Destkop System. And I was one of the core members of the Looking Glass project.

In June of 2005, I rejoined the Corporate Development group at Sun as a Sr. Director of Corporate Alliances where I help Sun navigate the waters of our strategic partnerships with companies like IBM, Dell, HP, ORacle and Red Hat.

Prior to Sun:

From 1995 to the end of 1996, I worked as the Corporate Systems Engineer for ParcPlace-Digitalk. For those of you not familiar with ParcPlace, we were the commercial spin-off from Xerox PARC dedicated to taking object-oriented programming to the masses through products and services around the Smalltalk language and runtime environment. Smalltalk was a clean, object-oriented, cross-platform language that ran in a Virtual Machine and was predicted to replace COBOL as the lingua franca for corporate development in the late 90's. Unfortunately, another object-oriented, cross-platform, VM-based language - Java - beat us to it :-)

Prior to ParcPlace, I worked for a couple of small, vertical market ISVs: Creative Computer Solutions (CCS) where I was working on software systems for Public Housing Authorities and Municipal Governments, and Ultradata where I was working on systems for Credit Unions and Commercial Bank. I was doing a variety of software development related jobs such as a development manager, product support manager and even a short stint as the VP of Marketing for CCS. Both of these companies used a little known but very powerful database management system known as "Pick". For those of you who care, there were several "flavors" of Pick including Ultimate, Microdata's Reality, Universe, Unidata and Prime Information.

Prior to Ultradata and Creative Computer Systems, I worked for McDonnell Douglas in the MIS group (what "IT" used to be called in the olden days) as a Systems Analyst. Actually, I started working for Tymshare (Silicon Valley old timers will remember them) and was acquired by McDonnell Douglas as they tried to diversify into the technology sector. I worked mostly on the projects that no one else wanted or were capable of handling. I did some COBOL development, some C development, some BASIC development, some FORTRAN development and a lot of development in a Pascal-like language called SAIL (Stanford Artificial Intelligence Language). I spent most of my time on projects written in a proprietary database called "Magnum" and on ancient DEC assembly code called Macro-10.

I have a degree in Business Administration with a concentration in Marketing. My minor was "Cybernetic Systems", the study of both human and non-human system (fascinating stuff).

more to come...

In response to my recent Blog on what Open Source Java advocates want, Keith Lea posted a comment that said:

I think it would work perfectly if Sun released something called something vague like "FreeVM" which is simply the JDK, under a BSD license, but not called Java in any way. Then, if you want to release a version of it, you have to submit it to Sun for testing to be able to call it Java. Otherwise it's called FreeVM or whatever the developers want to name it.

The problem with this is that it fails to address the fundamental problem from Sun's perspective - why would Sun want Java technology based on Sun's implementation (which is known to be compatible) to be distributed in an incompatible way, regardless of what it is called? If the answer is to leverage "innovation" of more developers, that assumes that the innovation is of more value than the compatibility. Sun has already determined that the JCP is the way to manage compatible innovations - agree to the standard specification first, then build reference implementations and test suites that allow multiple, compatible implementations of the standard. Is it really the "specify first, then innovate" approach that open source advocates disagree with?

Another message storm has blown in across the Java Lobby on if/when/how Sun should Open Source (empahsis mine) Java.

This is not the first or last time this will come up. But, as always, it boils down to a tension between the differing priorities for Java (compatibility) and Open Source (freedom). Having spent a great deal of time in the technology licensing group at Sun, I fully understand this tension and remain confident that both freedom and compatibility can be achieved if both sides would stop talking at each other and start talking to each other.

Here's one of the fundamental quandaries that I think needs to be addressed:

Both sides tend to agree that the Java logo and trademark is Sun's property and Sun's alone. And that Sun can and should use that trademark as a way to "rubber stamp" compatible implementations. And both sides tend to agree that no implementation of Java should be allowed to have that trademark if they have not passed an appropriate set of compatibility tests (although both sides do not necessarily agree on what is "appropriate" or how such tests should be made available).

But if it is clear that the Java logo can and should mean compatibility and that no incompatible implementation should be allowed to have the logo, isn't it also logical that no compatible implementation should be allowed to not have the logo? If the logo is truely going to mean compatibility, shouldn't it be required to be on compatible implementations? And once made compatible, shouldn't a given implementation remain compatible? After all, compatibility is a moving target - are you 1.1 compatible, 1.2 compatible or 1.5 compatible?

These (along with many other) are the reasons Sun has been reluctant to move down the open source path. Compatibility means certain responsiblities, not complete and unencumbered freedom. Without understanding and addressing these core tensions, the debate will rage on.

Wow - I can't believe it was August the last time I created a blog entry. I guess I've been busy.

Since August, I've gone through 2 additional re-orgs (on top of the one that happened in July), so I now work for my fourth boss in almost as many months. And we've managed to complete the integration of JDS into the Solaris WoS ("Wad of Stuff") - no small task. And our Linux version is in the middle of an extensive and lively beta.

So I'm getting ready now to collect some thoughts and get them out on my blog. More to come...

Jonathan has an interesting blog where he engages the topic of commoditization of software. He rightly points out that the elements of true commoditization as outlined in Ross Mayfield's blog do not really exist in software. And Jonathan has pointed out before that it really isn't about open source, it's about open standards.

Well, if Jonathan's right (and I believe he is), why is Sun involved in open source at all? For that matter, why is anybody?

I think first it's important to define the term "open source". The Open Source Initiative has seen fit to create a rather lengthy and specific definition of what constitutes "open source". The Free Software Foundation prefers to define similar concepts as "Free Software" rather than "open source", but is clear that "open source" means:

1) access to source and
2) rights to create and distribute modifications free of charge.

The OSI even goes so far as to create a list of "approved licenses" that it has determined meet this criteria. But for my purposes, since the discussion of what is or is not "open source" always boils down to the license itself, I'd prefer to simply refer to "open source" as any licensed technology that generally meets the above 2 criteria.

But remember that these are licenses generally executed by developers and the commercial companies that employ them, not the end users and consumers of the products built by these developers. End users of products based on open source typically execute some sort of end user agreement rather than an open source license directy. So clearly, "open source" is about developer adoption more so than end user adoption (although the two are quite clearly related).

Which brings me (finally :) to my point - it's not about open source or even open standards, it's about "open development". Open development is not simply making code available via one of the OSI approved licenses. It's about creating a community of developers that represent varying interests (commercial and non-commercial), harnessing their interests and efforts and advancing the technology based on collective priorities and requirements. Open development is hard work. It requires significant investment on the part of an original contributor and a set of project leads and maintainers that keep the project moving forward and meeting customer requirements. It is really no different than traditional commercial development from an overall effort standpoint, but it is open to all (not just a particular commercial interest) and it is controlled collectively rather than autocratically. Also, it tends to be an "early and often" process (i.e. code is made available early in the development cycle and is contributed continuously as the code is developed).

There are many examples of successful open development, the most notable of which is Linux itself. Notice that what I'm getting at is that Linux and its components are successful because of open development, not open source (although the former depends on some form of the latter). Sun execs - pay attention.

This is not to say that only open development projects will be successful. OpenOffice.org, MySQL and Ximan's Evolution are all open source projects that have arguably been very successful in their respective markets with little or no contributions from anyone other than the original contributors.

Nor is it to say that all open development projects will be successful. But I believe that increasingly the success or failure of new initiatives will focus on the ability of companies to create and harness open development communities that are enabled by open source. This is at the heart of Sun's recent decision to open source Project Looking Glass. And the nature of Sun's focus on "Network Computing" means that we will continue to drive the infrastructure and ubiquity of open, collaborative networks on which these communities are based. If we can figure out how to harness open development as well, there's no stopping us.