I just finished teaching a one-week course on agile methods at Tsinghua University, the top (mainland) Chinese engineering school and one of the two leading Chinese universities. My host told me that I was the first non-Chinese-speaking lecturer to have held such a short course, not only in Computer Science but at Tsinghua as a whole. (I’m sure there have been plenty of prior foreign lecturers, but apparently I was the first one not to teach for a whole semester, but only for this condensed one-week half-day type of course). Yay! Adventure and breaking new grounds is still possible on this planet.

Moreover, with my research partner Prof. Bai, I’ll be leading a joint distributed agile software development project, involving student teams from both Tsinghua University (THU) and Friedrich-Alexander University (FAU). The goal of the project is to learn about what makes or breaks distributed agile development. We’ll start with simple hypotheses but hope to grow this into something larger. We already have student teams, but are looking for more. If you are a software engineering student at either THU or FAU, please come and talk to us!

• on how I’m teaching startupinformatik at my University (in German),
• how that teaching feels like (the AMOS lab course) (in English),
• as well as recent spoils like Mydosis (others coming up).

Enjoy!

I’m an Addison-Wesley author and just received a letter from Pearson, the owner of Addison-Wesley, informing me about their thoughts and steps towards e-books and the digital age. The letter is written as an open letter with no apparent secrets, so I’m making it available here for anyone interested to read and to comment on it.

In general, I have sympathies with companies trying to sustain their revenue streams. I do expect them, however, to understand that change is inevitable and to flexibly react to and to lead that change for their customers’ sake and not just their shareholders’ sake. As an author, I’m naturally in a similar or at least related situation.

The PDF is marked up with numbers. The following list relates to what the (German) letter says on the respective issues:

1. Letter: “The e-book is entering mainstream [...]” – I’m glad to see Pearson realized that e-books are inevitable. While some may argue that’s hardly news I’m well aware of many publishers still fighting this development.
2. Letter: “It is important to maintain price control [...]” – I can also understand that distribution partners are trying to take their share of the revenue and that this is a major struggle for publishers who missed out on creating their own effective channels.
3. Letter: “We believe in the value of content you entrust to us [...]” – Naturally, as an author, I believe in the value of my books. I also hope that this value can be enhanced through e-books and ancillary services! I don’t agree that this naturally leads to DRM (Digital Rights Management) as a primary control mechanism. There may be reasons for and uses of DRM, but not as a general approach to e-books. Here is my thinking:
   • DRM is a nuissance and typically locks me into a platform. As a buyer, I don’t get the full freedom of use that I’m used from trad. books. Personally, I hate this. It is the primary reason why I never bought anything on iTunes and will keep a safe distance to all things Apple and proprietary lock-in.
   • DRM may be an intermediary solution until publishers figure out a better business model. As such, DRM is fighting progress, trying to keep us locked into “old ways of doing things”, thus reducing the potential for innovation and making us all worse off.
4. Letter: “[...] we use DRM to protect your content [...]” – I don’t like suggestive sentences like “it is important for authors to have their content protected” – who said that? Nobody says you should naively dump all works onto the net; the smart publisher uses the net for experimentation with new business models rather than trying to maintain the status quo.
5. Letter: “[...] Rough Cuts gives readers a pre-release version of a book [...]” – I’m reassuring publishers that innovation will happen, like this example given by Pearson here. So, publishers need to improve their ability to innovate, more rapidly. How to feature-differentiate? How to enhance value? How to provide complementary services? That’s Business 101.
6. Letter: “[...] how to consume books will be an important issue [...]” – So it is obvious to me that the publishing products of the future will be much more than just “books” as still suggested by much of this letter.

The good news? Innovation can open up new revenue streams. I actually believe that well-done e-books should cost more than the paper copy. If DRM didn’t get in the way, that is. I certainly would be willing to pay more for the added flexibility and benefits, and the main reason why I’m not doing it today is that I can’t stand the restrictions of being locked into some random platform trying to dictate my usage patterns.

As an author, shouldn’t I simply be behind Pearson supporting them in any way I can? After all, I’ll be getting more royalty payments if Pearson is making more money? The answer is obviously no, not just out of principle, but also because not pushing ahead with innovation is robbing me of additional revenues.

Read more on my research group’s blog.

A write-only research journal is a research journal that publishes papers but is never read (hence write/publish-only). Its purpose is twofold: to (a) give a researcher some reputation return on their work by having it pass (some form of) peer review and to (b) make money for publishers.

David Rosenthal explains the economics of write-only journals. Basically, by increasing the mass of their offering through easily produced write-only journals, publishers appear bigger in bundling deals with libraries and can charge more for the access to their overall offering. Rosenthal then goes on to discuss other problems with peer review, the academic system, etc. but these are other topics.

Obviously, “write-only journal” is a derogatory term. Good research should be published in outlets that are read, not just written to. However, with the abundance of research results, I think even write-only journals serve the small purpose of validating the research results and hence the work of the researcher. However, the implication of write-only is that the results are not worth much and hence that validation should not count as much either. Which is why some say these journals should be done away with anyway.

Introduction: This case, in my interpretation, is about the failure of traditional market research methods when applied to disruptive innovation. Market research methods like focus groups, interviews and surveys, and usability labs only tell product managers about potential incremental improvements of a product. Market research is good for sustaining incremental innovation. Market research doesn’t tell a product manager whether a proposed disruptive innovation is just a crazy idea or the next big thing. For such an innovation, product managers need to turn to introspection, outsiders or experiments. Also, dealing with disruptive innovation is particularly hard for organizations like Intuit that are intensely customer focused. As the case reports, Intuit spends significant amounts of time and resources on usability labs. Ironically, coping and introducing disruptive innovation is much easier for engineering-centric organizations, but that is another case.

The teaching note is available as a PDF file and an ODT file. The original free cases can be downloaded from ECCH. For your convenience, here are PDFs for E-381(A) and E-381(B).

Java is an important technology powering the modern web and in particular enterprise applications. It has a checkered intellectual property history, and with the recent acquisition of Sun, the Java creator and owner, by Oracle, things only stand to heat up. This slide set discusses some of the more interesting issues around Java intellectual property and its strategic use in business.

1. What is Java?
2. Short Java IP Story Time-Line
3. Three Substories
4. Java’s Challenge to the Windows Platform
5. Microsoft and Java
6. The OpenJDK Strategy (Open Core Model)
7. Certification of Compatible Implementations
8. Threats to Commercial Revenue
9. Main Tools to Curtail “Competitors”
10. Problems for Alternative Implementations
11. Problems for OpenJDK Forks
12. Thank you! and References

“Java” consists of multiple components [2].

• Java, the programming language, which has been standardized
• the JRE, which contains the necessary infrastructure to run Java applications
• the JDK, which is the JRE including its libraries and runtime, plus some tools
• in addition, there are many third party libraries and development tools

Java comes in multiple editions, which target different execution environments, most notably embedded, desktop, and enterprise systems.

Java, the programming language, is changing only slowly. However, the libraries are evolving at a rapid pace. To make them useful to industry, the JCP, the Java Community Process, defines specifications and develops reference implementations and compatibility test suites. The JCP was set up by Sun and brought together all relevant industry players with an interest in Java. To be allowed into the process, vendors have to sign the JSPA, the Java Specification Participation Agreement, which gives Java’s owner various rights to the specification output. The individual specifications are called the JSRs for Java Specification Requests.

Originally Sun, now Oracle, owns the following intellectual property rights:

• the Java trademark; this allows it to stop labeling other parties software as “Java” in the domain of information technology
• various JSR test suites; this output of the JCP serves to certify Java component implementations as specification compatible
• many patents in the implementation of the core Java programming language and runtime

These property rights are being used in various scenarios.

To get started, lets review a few key events in Java’s history [1]. Java was released to the public in 1996 under a proprietary license. Developers could use Java, but it wasn’t open source. With fast-rising industry interest, Sun announced and formalized the JCP in 1998 to help move Java forward by involving other industry players.

Microsoft was one of the industry players that adopted Java on its platform early on. Already in 1997 Sun filed a lawsuit alleging that Microsoft was not playing by the licensing agreement, and in 2001 Sun won this lawsuit. Microsoft has since removed Java from its platform leaving the integration to 3rd parties.

A first open source implementation of the Java tools, runtime, and libraries was begun in 1998 as the GNU Classpath project; it has yet to reach completion. The project uses the GPL open source license with a modification, the classpath exception, that allows linking of applications so that they don’t fall under the GPL.

Another open source implementation of Java was begun under the auspices of the ASF, the Apache Software Foundation, in 2005, labeled “Project Harmony”. Sun offers the non-profit community free Java certification if it was willing to accept certain field-of-use restriction for its software. The ASF objected on principled (open source) grounds, preventing it from using the Java trademark.

Sun itself released most of the Java tools, libraries, and runtime in 2006, finishing it in 2007, under the GPLv2 open source license. Called the OpenJDK, this is still the only complete open source implementation of Java available today.

I am going to tell three stories, in which intellectual property and business strategy come together:

• The Java vs Windows platform war
• Generating Revenues with the Open Core Model
• Curtailing Competition using Patents and Field-of-use restrictions

Questions of intellectual property and the legal system have a habit of boring one’s brain out; I hope this won’t happen in this case.

Java’s original marketing slogan (and promise) to software developers was to “write once, run anywhere” (WORA). It points to the most basic of industry strategies, the platform strategy.

In a platform strategy, a software vendor tries to make its software become the platform that everyone else builds on. By building applications on top of someone’s platform, these applications become dependent on the platform, and whenever a copy of the application is bought, a copy of the platform has to be bought too.

This is why Windows is so powerful and Bill Gates became so rich.

Java now challenged the Windows platform by completely hiding the Windows programming interface, the Win32 API, behind the Java class libraries. Thus, applications could be implemented using Java class libraries only without knowing whether these are run on a Windows or a Linux platform. This made applications portable across different operating systems and led to Java’s rallying cry of “write once, run anywhere”.

Of course, Java was simply trying to become the next platform to build on by hiding the underlying operating system, be it Windows or MacOS. Scott McNealy, the Sun CEO, probably wanted to become as rich as Bill Gates.

Microsoft didn’t like Sun’s Java strategy as it would reduce the lock-in of applications to the Win32 API and hence make application developers less dependent on Windows. Still, customers kept asking for Java on Windows. Eventually, Microsoft complied: Microsoft licensed Java from Sun and deployed it on the Windows platform.

According to a 1997 lawsuit by Sun, Microsoft did so only by violating the license agreement. Sun stated that Microsoft modified the JDK by omitting libraries that were needed to run Java well. This required application developers to go directly to the Win32 API. This strategic move was to maintain the lock-in to the underlying Windows platform that Java was trying to do away with in the first place.

Sun won the lawsuit in 2001, requiring Microsoft to pay damages. In the aftermath, Microsoft removed Java from its platform and introduced alternative technologies. Today, Java on Windows is provided by third parties only [3].

Knowing that Sun released Java as open source in 2007 and knowing that there were alternative implementations, you may be wondering how Sun ever intended to make money on Java. One answer to this is called the open core model today.

The release of the OpenJDK by Sun in 2007 gives developers a full Java development and runtime environment under the GPLv2 open source license. The license even comes with a modification called the Classpath Exception that allows software vendors to combine their application with the OpenJDK without having to open source their application code.

To not fully loose their (potential) revenue stream, Sun does two things, which taken together represent the core intellectual property strategy behind the open core model:

• Sun maintains the full copyright and thereby ownership of the OpenJDK code base. Any outside contributors first have to sign a joint copyright agreement [8]. While this curtails code contributions, it ensures that Sun remains the owner of the JDK.
• Sun then uses their ownership rights to offer the OpenJDK under a commercial license to those who don’t like the GPL (dual license strategy) while at the same time providing additional non-open-sourced functionality (open core model).

Thus, to get full service as well as enhanced features, Java application developers have to pay for the commercial license rather than use the open source license.

To win against Microsoft early on, Java needed to achieve rapid growth and industry buy-in during the 1990s.

Java could only grow as fast as it did, because Sun brought other major industry players on board. This was done through the JCP, the Java Community Process. In that process, companies like IBM, SAP, and anyone else who cares can influence the development of Java through library specifications and make sure it works well with their products.

One tangible output of the JCP is a stream of JSRs, the Java Specification Requests. Each JSR specifies a library or similar component. To each JSR specification belongs a TCK, the technology compatibility kit for the JSR. A TCK is effectively a test suite that checks a given implementation of the library for compliance with the specification. If the library passes, it is considered a compliant implementation. A Java TCK combines various JSR TCKs into a full test suite for a particular Java configuration.

Anyone with a Java implementation who wants a Java trademark license from Oracle first has to pass the matching Java TCK.

Rapid growth and the open core model meant that there could be serious business.

There was only one threat to those revenues: Alternative implementations. These are implementations of Java, including a JVM, tools, and class libraries. The first of these implementations, the GNU Classpath project, started as early as 1998 [17]. A later alternative implementation is the Apache Harmony project [16].

Because of the broad industry involvement, Sun and later Oracle couldn’t simply close off Java again after it grew to dominance as the leading enterprise programming language. Thus, Oracle today provides a defined way for industry to acquire a Java trademark license if it wants to label their Java implementation “Java”.

Today, Oracle makes the Java trademark license available in two main variants:

1. For paying customers, a full trademark license is granted, if the Java implementation passes the relevant Java TCK
2. For non-paying open source projects like GNU Classpath or Apache Harmony, a restricted license is granted

Option 1 works very well for Oracle, after all, it receives presumably appropriate revenues. Option 2 is not really an option for open source projects as we will see, but rather an attempt to prevent these projects from gaining traction.

With the OpenJDK, Oracle provides a full open source implementation of Java. However, in addition, Sun, now Oracle, made two strategic moves to curtail alternative implementations:

• The choice of the (1991) GPLv2 license because of its poor coverage of patents
• The field-of-use restrictions in the trademark license for open source projects

An open source Java implementation that wants to call itself “Java” has to pass the appropriate Java TCK. The use of the TCK and the Java trademark license is only granted for free, if the project (more precisely the organization behind it) accepts certain field-of-use restrictions for the project. As of today (2011), the main restriction is that the alternative implementation may not be used for embedded systems development. Enterprise applications, in contrast, are fine.

An example of an alternative implementation is the Apache Harmony project, which provides a comprehensive Java implementation under the Apache License 2.0.

The definition of Open Source Software requires that no field-of-use restrictions be imposed on the user. Oracle’s field-of-use restrictions are not acceptable to an open source project that wants to call itself that way [11] [12]. (And the same applies to free software.)

Game over for unrestricted free and open source Java implementations.

But what about forking the OpenJDK, wrestling it off the hands of Oracle?

In forking the OpenJDK, you face two options:

• If you want to put the “Java” label on your fork, you’ll have to pass the TCK and accept Oracle’s field-of-use restrictions. Since you are required to keep the software under the original GPLv2 license, this may hand you a GPL violation lawsuit, after all, you just accepted field-of-use restrictions which are incompatible with the license.
• If you don’t care about the “Java” label, you can forgo certification. However, without the certification, you don’t get a license to the software patents buried in the OpenJDK code. Thus, any patent owner who happens not to like you might decide to sue your customers who will turn back on you and will find you without patent defense.

One hope is Google’s Dalvik, once it digs itself out of the siege of patent lawsuits it is being buried under, but that will then be the Dalvik IP Story, not the Java IP story…

Game over, again.

For now.

[1] Oracle. The Java History Timeline.
[2] Wikipedia. Java (Programming Language).
[3] Microsoft. Microsoft Java Virtual Machine Support.
[4] Oracle. GNU General Public License, version 2, with the Classpath Exception.
[5] Wikipedia. GPL Linking Exception.
[6] Oracle. Oracle and IBM Collaborate to Accelerate Java Innovation Through OpenJDK.
[7] Oracle. Java SE at a Glance.
[8] Oracle. How to Contribute.
[9] Oracle. OpenJDK FAQ.
[10] Doug Lea. Email to JCP Executive Committee Members.
[11] Apache Software Foundation. Our Participation in the Java Community Process.
[12] Apache Software Foundation. Open Letter to Sun Microsystems.
[13] Paul Querna. Java Trap, 2010 Edition.
[14] Oracle. Java(tm) Compatibility Test Tools (Java CTT) Info.
[15] Wikipedia. Technology Compatibility Kit.
[16] Wikipedia. Apache Harmony.
[17] Wikipedia. GNU Classpath.
[18] Brian McCallister. The TCK Trap.

How and Why IT User Companies Sponsor Open Source

Abstract: Open source is not only a type of software, it is also a novel development and inter-firm collaboration model. IT user companies can use this collaboration model to counter increasing costs and undesired vendor lock-in. An increasing number of IT user companies in various industries are sponsoring open source and are creating open source user foundations to achieve these goals. This talk introduces the concept of open source user foundations and, using current examples, explains how existing IT user companies are working towards the goal of better controlling their IT destiny.

English Table of Contents

• Open source definition, time-line
• Professionalization of open source
• Current open source foundations
• Goals, core processes, governance
• Intellectual property arrangements
• Known dysfunctions and problems
• A blueprint for open source user foundations
• General model of open source user foundations
• Best practices and choices vs key levers and customizations
• A comparison of existing open source user foundations

Warum und Wie IT-Anwenderunternehmen Open Source Unterstützen

Zusammenfassung: Open Source bezeichnet nicht nur eine Art von Software, sondern stellt auch eine neuartige Methode der Softwareentwicklung und Kooperation zwischen Unternehmen dar. IT-Anwenderunternehmen können dieses Kooperationsmodell nutzen, um steigenden Kosten und unerwünschtem Vendor-Lock-In erfolgreich zu begegnen. Um diese Ziele zu erreichen, unterstützen IT-Anwenderunternehmen unterschiedlichster Branchen Open-Source-Software und gründen Open-Source-Anwendervereinigungen. Dieser Vortrag stellt das Konzept solcher Vereinigungen (Foundations, Konsortien) vor und erläutert unter Verwendung aktueller Beispiele, wie existierende IT-Anwenderunternehmen Open Source unterstützen und Anwendervereinigungen nutzen, um Ihre IT-Zukunft aktiver und erfolgreicher zu gestalten.

Deutsche Inhaltsangabe

• Open-Source-Definition, Zeitstrahl
• Die Professionalisierung von Open Source
• Heutige Open-Source-Vereinigungen
• Ziele, Prozesse, Governance
• Umgang mit geistigem Eigentum
• Dysfunktionen und Probleme
• Eine Blaupause für Open-Source-Anwendervereinigungen
• Ein allgemeines Modell von Open-Source-Anwendervereinigungen
• Erfahrungen, Erfolgsmethoden und Stellschrauben
• Ein Vergleich existierender Open-Source-Anwendervereinigungen

Today I received a letter from the journal’s editor, informing me that the paper had been rejected. The editor considered this a minor case of plagiarism, as it was not clear whether the author was doing this intentionally or simply had not had enough guidance and experience in academic conduct. The actual research work, while faulty and shallow, seemed original. Maybe putting the copied-from papers into the reference section had been smart way of guarding against accusations of malicious intent.

In a strange coincidence, today the University of Bayreuth declared the dissertation of one of its graduates, Karl-Theodor zu Guttenberg, former defense minister of Germany, a case of intentional plagiarism.

Quo vadis, academia?