August 27-29, 2012 | Linz, Austria

The International Symposium on Wikis and Open Collaboration (WikiSym) is the premier conference on open collaboration and related technologies. In 2012, WikiSym celebrates its 8th year of scholarly, technical and community innovation in Linz, Austria.  We are excited this year to be collocated with Ars Electronica, the premier digital art and science meeting that attracts over 35,000 attendees per year.

Submissions are invited for the following categories:

[1] As determined at the International Date Line. In other words, as long as it’s still April 7th or April 27 somewhere on Earth, the system will accept your submissions.

The conference program will include a peer-reviewed research track, experience reports, workshops, posters, demos, a doctoral consortium, invited keynotes and panel speakers. As always, the participant-organized Open Space track will run throughout the conference. Evening social events will follow, because wiki folks know the value of a good party for sparking conversation and collaboration. Finally, WikiSym co-occurs with Ars Electronica, and we are arranging experiences where conference attendees can enjoy this innovative and unusual event.

Topics appropriate for submissions include all aspects of the people, tools, contexts, and content that comprise open collaboration systems. For example:

• Collaboration tools and processes
• Social and cultural aspects of collaboration
• Collaboration beyond text: images, video, sound, etc.
• Communities and workgroups
• Knowledge and information production
• New media literacies
• Uses and impact of wikis and other open resources, tools, and practices in fields and application areas, for example:
• Open source software development and use
• Education and Open Educational Resources
• E-government, open government, and public policy
• Law/Intellectual Property (including Creative Commons)
• Journalism (including participatory journalism)
• Art and Entertainment (including collaborative and audience-involved art)
• Science (including collaboratories)
• Publishing (including open access and open review models)
• Business (including open and collaborative management styles)

In addition to research and development topics, WikiSym also invites innovative proposals for open, collaborative art and performance.  These proposals should be made directly to the conference chairs.

General submission instructions and information

All accepted submissions will be published in the WikiSym proceedings and archived in the ACM Digital Library. Long and short research papers will be rigorously peer reviewed and treated as archival publications. Submissions to other tracks will also be reviewed and appear in the ACM DL, but they are considered to be non-archival and may be used as the basis for later publications. Authors of research papers should use the ACM/CHI SIG Proceedings Format, and other contribution types will use the ACM/CHI Extended Abstracts Format. Templates for both formats are available at http://www.acm.org/sigs/pubs/proceed/template.html.

General submission instructions will be posted and the conference submission site opened around March 1. Instructions for the various contribution types are below.

Research Papers – Long (up to 10 pages) and Short (up to 4 pages)

Research papers present integrative reviews or original reports of substantive new work: theoretical, empirical, and/or in the design, development and/or deployment of novel systems.

Research papers will be reviewed by the Program Committee to meet rigorous academic standards of publication. Papers will be reviewed for relevance, conceptual quality, innovation and clarity of presentation. They should be written in English and must not exceed 10 pages (for full papers) or 4 pages (for short papers). At least one author of accepted papers is required to attend the conference in order to present the paper.

Workshops (up to 6 pages, Extended Abstracts format)

Workshops provide an opportunity for researchers and practitioners to discuss and learn about topics that require in-depth, extended engagement such as new systems, research methods, standards, and formats.

Workshop proposals should describe what you intend to do and how your session will meet the criteria described above. It should include a concise abstract, proposed time frame (half-day or full-day), what you plan to do during the workshop, and one-paragraph biographies of all organizers. Workshop proposals will be reviewed and selected for their interest to the community. Each accepted workshop will be provided with a meeting room for either a half or full day. Organizers may also request technology and materials (projector, flip pads, etc).

Panels (up to 6 pages, Extended Abstracts format)

Panels provide an interactive forum for bringing together people with interesting points of view to discuss compelling issues around open collaboration. Panels involve participation from both the panelists and audience members in a lively discussion. Proposals for panels should describe the topics and goals and explain how the panel will be organized and how the Wikisym community will benefit. It should include a concise abstract and one-paragraph biographies of panelists and moderators. Panel submissions will be reviewed and selected for their interest to the community. Each panel will be given a 90-minute time slot.

Experience Reports (up to 16 pages, Extended Abstracts format)

Experience reports are an integral part of the conference program. These are opportunities to discuss how ideas that sound good on paper (and at conferences!) work in real life projects and deployments. Many attendees want to learn from people on the front lines what it is like to do things like start a company wiki, use open collaboration tools in a classroom, or build a political campaign around open collaboration systems. Experience reports are not research papers; their goal is to present experience and reflections on a particular case, and they are reviewed for usefulness, clarity and reflection. Strong experience reports discuss both benefits and drawbacks of the approaches used and clearly call out lessons learned. Reports may focus on a particular aspect of technology usage and practice, or describe broad project experiences.

Posters (up to 4 pages, Extended Abstracts format)

Poster presentations enable researchers to present late-breaking results, significant work in progress, or work that is best communicated in conversation. WikiSym’s lively poster sessions let conference attendees exchange ideas one-on-one with authors, and let authors discuss their work in detail with those attendees most deeply interested in the topic. Poster proposals may describe original research, engineering, or experience reports. Successful applicants will display their posters, up to 1x2m in size, at a special session during the Symposium.

Demos (up to 4 pages, Extended Abstracts format)

No format is better suited for demonstrating the utility of new collaboration technologies than showing and using them. Demonstrations give presenters an opportunity to show running systems and gather feedback. Demo submissions should provide a setup for the demo, a specific description of what you plan to demo, what you hope to get out of demoing, and how the audience will benefit. A short note of any special technical requirements should be included. Demo submissions will be reviewed based on their relevance to the community.

Doctoral Symposium

The WikiSym 2012 Doctoral Symposium is a forum in which Ph.D. students can meet and discuss their work with each other and a panel of experienced researchers and practitioners. The symposium will be held on Tuesday August 28 on the campus of Johannes Kepler University. More information about the symposium’s leaders, goals, submission process and criteria, and funding will be posted shortly.

Open Space

For short and informal opportunities to organize discussion, brain-storming, and other collaborative activities, the Open Space track will run throughout WikiSym. Open Space is an entirely participant-organized track and requires no submission or review.

Note on Publications

Work submitted to Wikisym is published in the ACM digital library. This means it is not open access. However, ACM has a very new service called ACM Author-izer which allows authors to post official copies of their papers on personal websites for people to access, even if those people do not have access to the ACM digital library. We see this as a step to open access and are pleased to support this service.

http://www.acm.org/publications/acm-author-izer-service

Keywords: Wiki, Wikipedia, Wiki Parser, Wikitext Parser, Parsing Expression Grammar, PEG, Abstract Syntax Tree, AST, WYSIWYG, Sweble.

Reference: Hannes Dohrn and Dirk Riehle. “Design and Implementation of the Sweble Wikitext Parser: Unlocking the Structured Data of Wikipedia.” In Proceedings of the 7th International Symposium on Wikis and Open Collaboration (WikiSym 2011). ACM Press, 2011.

The paper is available as a PDF file (preprint).

Keywords: Wiki, Wikipedia, Wikitext, Wikitext Parser, Open Source, Sweble, Mediawiki, Mediawiki Parser, XWML, HTML, WOM

Reference: Hannes Dohrn and Dirk Riehle. WOM: An Object Model for Wikitext. University of Erlangen, Technical Report CS-2011-05 (July 2011).

The technical report is available as a PDF file.

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.

The figure shows the growth of active well-working open source projects of all sizes over time, as captured in our database [1]. Each line represents a particular year, from 1995 to 2008. Each line shows how many projects of a particular size existed in that given year. The x-axis shows the size of projects, and the y-axis shows the number of projects of that size. So, for 1995, we can see that there were 10 projects of size 1 committer. (The scales are logarithmic [2].) Using the number of registered committers as a proxy for a project’s size is most certainly a conservative assumption. In 1995, there were also 4 projects of size 10 committers. In 1996, there were already more smaller projects and also more larger projects.

As you can see, the number of smallest projects (one committer) kept growing over time and reached about 3.200 in 2008 in our sample. At the same time, some of these smallest projects kept growing, migrating to the right in the figure. In 2008, there were 10 projects of size 1.000 committers! (While in 1995 there were none.) I find this continued growth of open source intriguing. Speculating from the expansion of the year lines there is a constant supply of new projects, and each project grows to the size right for it, including some very large project sizes.

Mathematically, of interest is the gradient over the year lines. The gradient is the formula that captures the year-over-year growth. I call the figure an illustration of the open source big bang, because the gradient captures the expansion speed of the growing open source universe. We have not yet been able to develop an appropriate mathematical model for this apparent growth. However, the figure illustrates how open source projects consistently scale to the largest project sizes. We may not yet know exactly why, but we are measuring that they do.

If you liked this blog post, you might also like reading about

1. Open source practices for internal software development (a.k.a. inner source)
• Inner Source / Benefits / Platform Development Scenario
• Inner Source / Benefits / Selbstorganisationszenario (in German)
2. How to go to to market with an open source strategy
3. The economic case for open source foundations
4. My current presentations on open source

Footnotes and References

[1] The data used to generate the figure was taken from an Ohloh.net database snapshot from March 2008. That snapshot contains about 30% of all active open source projects at that time, using Carlo Daffara’s estimate of total population as well as activity. The year lines in the figure are not the result of precise mathematical modeling, rather they are a linear regression fitted into the logarithmic data. Thus, this figure serves eyeballing purposes only. The figure itself was created by my Ph.D. student Carsten Kolassa.

[2] A short reminder on logarithms, in case it got rusty: 10^0 = 1, 10^0.6 = 4 (roughly), 10^1 = 10, etc. The exponents are to be found on the x and y-axes.

So what about this “cracking the MediaWiki code”?

Wikipedia aims to bring the (encyclopedic) knowledge of the world to all of us, for free. While already ten years old, the Wikipedia community is just getting started, and we have barely seen the tip of the iceberg, there is so much more to come. All that wonderful content is being written by volunteers using a (seemingly) simple language called Wikitext (the stuff you type in once you click on edit). Until today, Wikitext had been poorly defined.

There was no grammar, no defined processing rules, and no defined output like a DOM tree based on a well defined document object model. This is to say, the content of Wikipedia is stored in a format that is not an open standard. The format is defined by 5000 lines of php code (the parse function of MediaWiki). That code may be open source, but it is incomprehensible to most. That’s why there are 30+ failed attempts at writing alternative parsers. That’s why a respected long-time community member asked in exasperation: Can anyone really edit Wikipedia?

The common answer given is to hide the complexity of Wikitext behind a visual editor, but that is not an answer. It doesn’t work: A visual editor, like any other algorithm that wants to work with Wikipedia content, needs a well-understood specification of the language that content is written in. This is where the Sweble parser comes in. Following well-understood computer science best practices, it uses a well-defined grammar that a parser generator uses to create a parser. It uses well-understood object-oriented design patterns (the Visitor pattern, prominently) to build a processing pipeline that transforms source Wikitext into whatever the desired output format is. And most importantly, it defines an abstract syntax tree (AST), document object model (DOM) tree soon, and works off that tree. We have come a long way from 5000 lines of php code.

So what does creating an AST and DOM tree for Wikitext buy us?

In short, it buys us interoperability and evolvability. In a 2007 paper, using the then hopeful wiki markup community standard WikiCreole, we explained the need for such interoperability and evolvability as defined by an open standard. Different tools can gather around that format and evolve independently. Today, everything has to go lock-step with MediaWiki. By untying the content and data from MediaWiki, we are enabling an ecosystem of tools and technology around Wikipedia (and related project) content so these projects can gain more speed and breadth.

Abstract: Open source is not just software but also represents a new approach to software development. This type of software development is different from traditional plan-driven and agile methods and scales up to the largest project sizes. In this talk, I’ll show how open source differs from prior approaches and addresses questions of globally distributed software development. I’ll first present surprising results from quantitatively analyzing open source projects that show how open source software development actually proceeds. I’ll then use these insights to motivate new software engineering tools and show some examples. Finally I’ll discuss how software forges, a novel type of platform for collaborative software development, can complement current project management approaches to improve code reuse and knowledge sharing and to more effectively use developer resources.

Biography: Prof. Dr. Dirk Riehle, M.B.A., is the Professor for Open Source Software at the Friedrich-Alexander University of Erlangen-Nürnberg. Before joining academia, Riehle led the Open Source Research Group at SAP Labs, LLC, in Palo Alto, California (Silicon Valley). Riehle founded the Wiki Symposium, a conference dedicated to wiki research and practice. He was also the lead architect of the first UML virtual machine. He is interested in open source software engineering and agile methods, complexity science and human collaboration, and software design. Prof. Riehle holds a Ph.D. in computer science from ETH Zürich and an M.B.A. from Stanford Business School. He welcomes email at dirk@riehle.org, blogs at http://dirkriehle.com, and tweets as @dirkriehle.

That said, every time I visit the museum, I ask about the state of curating, preserving, and showing not only hardware, but also software. Like most exhibitions, the R|Evolution exhibition focusses on physical objects and complements them with textual explanations on plates as well as videos. Software is being discussed in the Software Theatre and in some smaller videos. However, these videos are about software and programming in general, not about actual software artifacts. Software is mostly shown through physical objects, i.e. the boxes they came in as packaged software.

Packaged Software Box Arc

This is hardly a form of presentation that brings out the beauty of software code, how software works, and how paradigms changed over time. Also, I saw no presentation of non-packaged software and open source and open data was completely missing.

The significance of software is being recognized though. At the exit of the exhibition, you’ll find a video wall with short snippets and statements of notable people, and my impression was that whenever they focussed on what computers do for us, software was at the forefront.

This brings me to the question of software preservation and show-casing. Clearly, the way it is currently being done is sub-optimal. Videos and boxes don’t really convey much of what people need to understand about software.

I looked at the CHM’s Software History site to see whether they have any progress to report but this doesn’t seem to be the case: The last report dates 2004 and the site’s footer itself says 2007. Seems this effort is stalled.

Preserving the raw data is only the obvious first step. Preservation and show-casing seem interesting topics to me. Software doesn’t mean much without context, so you’d need to collect emulators, configuration information, and usage patterns to run the software. But even running software doesn’t help much, and it certainly doesn’t speak to the average museum visitor. So you’d want visualization of program execution, configuration management history, etc. A rich topic, and I encourage everyone to ask the museum staff about the state of software preservation.

I hope that the next exhibition at the CHM will be able to unlock the beauty of the Linux Kernel’s code, Microsoft Word’s interaction design, and Apache’s httpd subversion history in front of my eyes.