peac-cat-poster-01.jpg

“When programmers on the Internet can read, redistribute and modify the source for a piece of software, it evolves. People improve it, people adapt it, people can fix the bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.” – The Open Source Initiative

The above shows why people care about open source, from a technical viewpoint. What’s missing are the companion thoughts that should go into the value of open source.

First, let’s review:

Open source rules are, simply enough:
Allow Free redistribution.
Allow Source code access.
Permit derived works.
Protect the integrity of the author’s source code.

These are pretty darn clear. (And debatable, but that gets us into licensing hell).

So what are the rules for using open source from a corporate view?

They are even easier.

Give credit where credit is due.

If you use someone else’s program, work, code fragments, or anything of the ilk, give them credit. This actually should go beyond open source; it’s a good rule for life. For example, when I was back at Cassatt Corporation, we built a complex automation control system, which makes use of other programs, and thus we created a “thanks to” page. (Don’t ask why it’s in the legal section). If you notice, it’s lengthy, and yet clearly recognizes that using open source for development, for delivery and so forth, reduces Cassatt’s industry-leading datacenter automation tools development complexity.

Return value equivalent to what is received.

Note, this doesn’t say, “Open source your products” or “All your base are belong to us“. This means if you get something, give something back. It can be in recognition, in other projects, in hosting (live or web), or opening other code. At SGI when we decided to adopt Linux, we also decided to identify and release code that would add value, such as XFS. We didn’t open IRIX (the operating system) since it was encumbered with OPS (Other Peoples Stuff), like trademarks, copyrights, and licenses.

Today, many, many companies make use of quality code that they received from what was, in end view, an open source effort. Let’s hope that somewhere, the non-zero-sum game that makes up open source usage is being played both competitively and cooperatively.

As always, comments welcome.

Over the past few years, many companies have decided, for various reasons, to release programs into the wild world of open source. Some few have done it well, more have flopped.

So, in the interest of goodness, I’ve decided to drop my list of things to think about, and hopefully get some feedback on what other things should be included, ignored, expanded; you get the idea.

So, with litle ado.

Open Source Decision Criteria
1.0 Does Anyone Care?
1.1 Who cares internally
1.2 Who cares externally

2.0 What is the reason for open sourcing this?
2.1 Increase business
2.2 Drive new development
2.3 be a Good citizen

3.0 Who owns the project
3.1 Who is the gatekeeper
3.2 How are developments accepted and merged
3.3 Who will host this project

4.0 Open source isn’t free.
4.1 Is the company willing to pay the tab
4.1.1 Engineering?gatekeeper/Integration
4.1.2 Marketing/Promotion
4.1.3 Legal

5.0 What are the legal issues
5.1 Is the code IP clean (or acceptable)
5.2 Is the code dependent on other products
5.3 What license is being considered
5.3.1 is there a dual use license scheme available

6.0 What shape is the code in
6.1 Are you willing to have others review the code
6.2 What’s the current known buglist like
6.3 How long would it take an average programmer to get up to speed on the code
6.4 Is there any documentation

7.0 What’s unique to this program
7.1 What are the unique features
7.1.1 and again, who cares (and why)
7.2 What other projects are targeting/delivering this
7.2.1 Would you consider using one of them if your own project didn’t exist
7.2.2 Have you had discussions with any of them on merging

8.0 Does the product have commercial iinterest
8.1 Will you create competition
8.2 Is there a potential SAAS or services tie-in
8.3 Will you continue to offer the project directly as a commercial entity
8.3.1 Have you thought (again) about dual license
8.3.2 Do you plan to extend the capability outside of the open source arena

Taking a product/project from a closed world to an open one is never easy or trivial. If you can’t at the least answer the above, don’t bother going there.

Also, I suspect there are many things that should also be considered… let me know.

With few doubts, the buzz on open during the last few years has obscured the basics of openness in a wash of white noise. Please note this is not just a concept of open source (though open source plays a role in openness; it is about a broader concept of open).

Openness in technology is a component of interactions. In short, a conversation between applications (interoperability), within components (interfaces), or even between the organic side and the silicon side (user interactions) requires an open. For open source, this conversation may include the ability to modify the conversation in ways unforeseen by its instigator. In short, being open really evolves to allowing access to the information necessary to take an appropriate action, or on accommodation, as in the ease in adapting to changes on either side.

So let’s consider some of the degrees of openness.

First, any conversation on open can be traced to currency. (I can hear the screams now…)

Currency doesn’t necessarily mean government-issue cash. Back in the early days of the (now historic) Open Source revolution, I was often asked (usually by executives in big companies) how Linux development got paid for. The answer, easily enough in the early days, was ego-dollars. Developers got to see their creations used by lots of people, got kudos for good code and lost value for bad code. Now it is often those same companies paying employees to extend and enhance open source code.

So, for a corporation, openness can be a good thing (expand reach, expand share) or a bad thing (devalue products, reduce profit). However in most cases, openness as a communication vehicle is of benefit to everyone. Imagine having to purchase a phone for each telephone network that your friends might have. We enjoy having the ability to plug our coffee pot into an available plug.

Similarly in technology, openness helps delineate how we connect. While it may extend into visibility into the implementation, source is in itself not a communication necessity. With exceptions, most of us don’t know or care how the electricity is generated; we care that we have electricity. Neither do most of us care about the choice of programming language, programming style, or reuse of the code.

Openness can exist in many layers, but for shortness, I’m going to break this into some subsets.

1. Programming Interfaces: By making the communication conduits and language (values) available, programs can implicitly exchange information and interoperate. This does require a level of trust in the implementation, since what the program does is hidden. APIs are usually a one sided affair, changes can occur without regards to impact.

2. Specifications: Often you can find specifications that are available without business restrictions, from which you can build a product to manipulate or interchange. For example, back in 1999, SGI released the specification of XFS to allow developers to understand the technology, as well as develop to it. However, specifications can come in two basic flavors: read-only and read-write. Read-only limits the changes to the originating organization without allowing outside input. Often defacto standards fall into the realm. Read-write allows community input.

3. Standards organizations: The nice thing about standards is there is always one to do what you want. The downside is that there are innumerable standards bodies, from industry, through national to international, covering a multitude of arenas with non-standard ways of determining what and how to create a standard. This class falls in dejure standards.

4. Open Source: Obviously the most open way of communicating is to determine both the content and the intent of any message. By allowing view (and modification) of source, open source delivers a level of openness found in no other layer. However, standardization in open source is only driven by the will of the community.

Each of these has strengths and weaknesses, pro and con arguments. As we move forward, we’ll delve into each of these.

I want to close on my new favorite openness quote, from Arthur Kantrowitz in “The Weapon of Openness” :
“When technical information is classified,
public technical criticism will inevitably degrade
to a media contest between competing authorities.”

As always, comments welcome.