In Vitruvius’ Ten Book on Architecture, Chapter 1, The Education of the Architect, Vitruvius calls for a wide foundation of knowledge for the architect, including art, math, history, philosophy, music, and medicine.  That a good architect should strive for a breadth of applicable knowledge.

He also points out the usefulness of understanding the nature of practice and theory in all of these subjects, that a balance should be maintained.

2. It follows, therefore, that architects who have aimed at acquiring manual skill without scholarship have never been able to reach a position of authority to correspond to their pains, while those who relied only upon theories and scholarship were obviously hunting the shadow, not the substance. But those who have a thorough knowledge of both, like men armed at all points, have the sooner attained their object and carried authority with them.

I would argue that the same logic is very well applied to our occupation today, in that over-specialization is not particularly suited to success.  That is, EA practitioners are IMHO better as generalists, with a breadth of knowledge, both technical, and non-technical.

For my part, I typically look for experience and success in the following areas:

• business (corporate and entrepreneurial)
• software development (multiple languages and types [OO, functional])
• systems administration
• creativity and problem solving skills
  
• engineering
  
• open source
• open standards
• development methodology
  
• Unix/Linux
  
• marketing
• writing
• speaking/presenting
• more…
  

In the real world, I see too many architects relying upon theory alone (hunting the shadow as it were), create problems for themselves and their teams.  For this reason, I’m a big fan of the people at CodingTheArchitecture.

Ten Books on Architecture from Project Gutenberg:
http://www.gutenberg.org/files/20239/20239-h/29239-h.htm

Originally Posted by john joseph roets at the-enterprise-architecture-network Google group, an example of reuse in writing.

Post in complete context here:
http://tinyurl.com/a8w5tk

From Sun:

WADL is designed to provide a machine processable protocol description format for use with such HTTP-based Web applications, especially those using XML.

A WADL file is an XML based language specification used to describe WEB-based applications. These files define resources, methods, requests and responses. The WADL project (https://wadl.dev.java.net/) houses the language specification as well as a wealth of other information including source code, examples and documentation.

wadl2java Utility

The WADL project also provides a Java utility called wadl2java. Wadl2java produces Java stubs from WADL files. The utility can be called directly from the command-line or as an Apache Ant task. At first I was a little baffled over how this utility worked. So, I decided to email the creator, Marc Hadley, with some questions. I was pleasantly surprised that he answered my questions. My concern was that wadl2java requires separate tasks and output directories for every WADL file. I’m use to having all generated classes contained within the same directory. Marc pointed out that even if he changed wadl2java to allow for this, the possibility still existed that a conflict could arise when two separate WADL files specified an XML element or attribute with the same name. Whichever WADL file was processed last would generate a class that overwrote the preceding. Wow, the light bulb went off, now I understood why it works the way it does. This was a conscience design decision to avoid class-naming conflicts, thus the utility must place these files in separate directories. In other words, if you were creating an application that consumes the services of two separate applications described by their own WADL files, two separate ant tasks would be required to produce the class stubs. Three applications would require three ant tasks, and so on. The generated stubs must be placed in independent output directories or the results from the second WADL would overwrite at least the end-point of the first WADL, as well as any other like-named classes. To avoid this, wadl2java has some built-in dependency checking that can be specified within the ant task.

Areas for Improvement?

Since the WADL project provides documentation I won’t go into details about the specification. However, I would like to point out a few areas that I found a bit confusing. When creating a WADL to describe an application, the ‘method’ reference has an ‘href’ attribute whose value must be prefixed with a pound ‘#’ sign. I see no practical reason for this requirement and would suspect that the WADL utilities can be programmed in such a manor to eliminate it. Additionally, the ‘href’ attribute actually is associated with the ‘id’ attribute of the ‘method’ definition such that the value of the ‘href’ attribute in the ‘method’ reference minus the pound ‘#’ sign refers to the value of the ‘id’ attribute in the ‘method’ definition. This is confusing because the labels used for these attributes are not consistent. Here I would suggest that both attributes be labeled the same. If it makes sense to use ‘href’ then both should be ‘href’. Otherwise, both should be ‘id’.
Another confusing area is the ‘method’ definition’s ‘name’ attribute. A ‘name’ attribute is usually an attribute used to identify something and is similar in function to how the ‘id’ attribute is being used. However, is this case, the value of this attribute really refers to the HTTP method type used to access the application. I would suggest that the attribute be labeled as ‘type’ or something similar.

Finally, the use of a ‘description’ attribute within the wadl2java’s ant task concerns me. This task uses the ‘description’ attribute to indicate the name of the WADL file one wishes to process. This is a little puzzling. Most Ant tasks I’ve seen make use of a ‘description’ attribute to provide a means for adding comments or further information regarding the particular task being performed. Maybe a better label for such an attribute would be ‘file’.

Overall…

Generally the WADL specification and its related tools excite me. I would recommend its use to anyone seeking a simple yet powerful means to describe any WEB-based application.
For more information about WADL please check out their site at https://wadl.dev.java.net/.

Originally published May 23, 2007.

What the Classics Say

While this is not untrue, a review of classic architectural writings reveals a fuller and more enlightened perspective. In point of fact, Architecture is about the spaces and the structure and the foundation. Physical Architecture does in fact concern itself in no small manner with the structure and foundation of the building. Without a solid and proper foundation, even the best and most suitable “spaces-based” Architecture will fail. The spaces based viewpoint might come from the fact that in the world of physical Architecture, structures and foundations are usually a known quantity, as a great deal of experience has been recorded over the past few thousand years. However, whenever a new material or technology is introduced, inherent unknowns often produce failure. With this failure and its study comes further understanding.

Software Architecture

In our world of software and systems Architecture, the foundation is the technology upon which one builds. Without an experienced based, solid foundation, even the best system will fail. Unfortunately, we do not have the advantage of thousands of years of direct experience to tap in our decisions of foundation and structure as do the physical Architects. Many modern software Architects start and end with what they already know, or let developers, politics, or circumstances decide. This is a short-sighted path. At createTank, we’ve seen success in recommendations based upon information from two primary sources:

1. Direct experience on hundreds of major projects in all variety of form and function.
2. Interdisciplinary Architectural research.

In this way, we can put to good use those abstract principals refined over thousands of years of physical Architecture, made concrete and applicable through direct experience doing modern, “dirty hands” work. When combined, these sources provide a more holistic architectural perspective. We are not perfect, nor claim all answers, but the proof is in the pudding, and one well built system is worth a thousand white-board rectangles.

The createTank perspective

Architecture is not only about technology, but it does concern itself with technology. That is, Architecture is not only concerned with the space, but also the structure holding up and indeed defining that space. This is the technology aspect of architecture. Without a solid foundation and structural components, any building or structure will fail. Enterprise Architecture’s virtual constructs are no different. The best design, the best architecture, will be hampered by a weak foundation, whether in the O/S, software language, or framework chosen. This is stated in confidence, because although the actual system may indeed function well, lack of scalability, maintainability over time, or agility to integrate with other systems will catch up in time and prove expensive or fatal.

Summary

In the end, ZapThink is not necessarily wrong in their assertion, the assertion is just incomplete. It is easy to understand as they are trying to highlight the business value of SOA. However, downplaying the role of technology in SOA to such an extent is unsettling. Walls are important in physical architecture, and technology is important in your software architecture. It might not be continually considered the most important component of your architecture, but an architecture should only be considered healthy when the foundation (its technology) is trusted solid and sound. Walls and structure, as too, technology, hold up and define the space or functionality designed. In essence, a good architect MUST understand the technology involved, including which technology best fits a given problem, in order to create the best possible system. This is absolute. In your projects, you would do well to place stock in the hire or counsel of an architect with extensive experience in the technologies involved and with the ability to communicate the lessons learned therein at multiple levels.

…the traceries had caught the eye of the architect…up to that time…his eye had been on openings only…Now, the great pause was at the moment when the space and dividing stone-work were both equally considered — John Ruskin, The Seven Lamps of Architecture, The Lamp of Truth, Section XIII.

^* “Physical Architect” is used here to jointly differentiate architects of physical structures (e.g. buildings, houses, industrial complexes, skyscrapers, etc.) from architects of more virtual structures (e.g. software systems, software applications, enterprise IT systems, etc.).

HttpUnit is a Java testing framework, which is used to access Web-based content in a manor similar to that of a Web Browser. Most things a user can do through a Web browser can be emulated with HttpUnit. It even supports form submission, JavaScript to a degree, and https. Additionally, HttpUnit allows one to examine the returned pages.

Let’s examine a very simple HttpUnit example by testing one of my favorite sites, http://carcruises.com. This site lists a considerable amount of car cruises within the US by month and state passed to the server in the form of query parameters. We want to test the results of querying for a list of cruises in Pennsylvania for the month of June.

First, we must create a class to extend the junit.framework.TestCase class. This is necessary to take advantage of JUnit’s assert methods. Within this class we create a test method (testGetPAJuneCarcruises) where we will emulate an http call to the car cruises website.

Listing 1
public class CarCruisesTest  extends junit.framework.TestCase {
    public void testGetPAJuneCarcruises() {
        String sURL = "http://carcruises.com/" +
            "cruise_list.asp?month_select=6&" +
            "state=Pennsylvania";
        try {
            // Create the conversation object,
            // which will maintain state for us
            WebConversation conversation = new WebConversation();
            WebRequest request = new GetMethodWebRequest(sURL);
            WebResponse response = conversation.getResponse(request);
        } catch (Exception ex) {
            ex.printStackTrace();
            // Fail the test if an exception is thrown.
            super.fail(ex.getMessage());
        }
    }
}

Listing 1 illustrates 3 significant lines of code. Initially we must instantiate a WebConversation object. This object is responsible for maintaining the session of the connection just like a Web Browser does when a human is looking at the URL. Next, we must create a WebRequest object pointing to the URL. This object can be a “GET”, “PUT” or “POST” request. Finally, we create a WebResponse object used to retrieve the results of the request.

OK, so that was easy enough but we haven’t tested anything. Usually it is standard practice to invoke JUnit assertNotNull methods on each of the objects (which is why our class must extend junit.framework.TestCase). Therefore, after instantiation of each object perform an assertNotNull as illustrated in Listing 2. If any of the objects are null the test will fail before moving on to the instantiation of the next object.

Listing 2
public void testGetPAJuneCarcruises(){
        String sURL = "http://carcruises.com/" +
            "cruise_list.asp?month_select=6&" +
            "state=Pennsylvania";
    try {
        // Create the conversation object,
        // which will maintain state for us
        WebConversation conversation = new WebConversation();
        assertNotNull("New conversation", conversation);
        WebRequest request = new GetMethodWebRequest(sURL);
        assertNotNull("Request to URL "+sURL,request);
        WebResponse response = conversation.getResponse(request);
        assertNotNull("Response from URL " + sURL,response);
    } catch (Exception ex) {
        ex.printStackTrace();
        // Fail the test if an exception is thrown.
        super.fail(ex.getMessage());
    }
}

If all of our objects are not NULL then we are ready to take a closer look at the WebResponse object. We’ll want to test for a valid response code by using the WebResponse object’s getResponseCode. If this method returns a 200 then we can test for other response objects. For example, we can test that the response message returns “OK” by making a call to the WebResponse object’s getResponseMessage method. Typically responses from Web applications also contain titles. We can test for a title by performing an assertEquals using the WebResponse object’s getTitle method. Snippet 1 illustrated these three tests.

Snippet 1
assertEquals("Response code should return 200",
    200, response.getResponseCode());
assertEquals("Response message should return OK",
    "OK",response.getResponseMessage());
assertEquals("Car Cruises Online - Cruise Listing",
    response.getTitle());

If theses assertions are correct we can begin to look at forms and links. Snippet 2 demonstrates the methods necessary to retrieve this data from the WebResponse object. Since more than one form or link can be present in any one response, the methods return arrays of type WebForm and WebLink respectively. For our example we know there is only one form in the response so we first test for NULL then we test the array length to make sure we only received 1 form. As for links, our example is using a dynamic URL in which the number of links can change at any time. Therefore we just test for null and then to be consistent we check the array length to make sure it is greater than or equal to 0.

Snippet 2
WebForm[] forms = response.getForms();
assertNotNull(forms);
assertTrue("Response should contain only 1 form",forms.length == 1);
WebLink[] links = response.getLinks();
assertNotNull(links);
assertTrue("Response should contain 0 or more links",links.length >= 0);

Each of the WebForm and WebLink objects can be further broken down into other objects. Each URL may or may not utilize this inner objects. Some of these objects are Buttons, Methods, Parameters, and so on. Likewise, the WebResponse object can be further broken down into other objects. Please see the HttpUnit javadocs for more information (http://httpunit.sourceforge.net/doc/api/index.html).

Another interesting thing to note is that usually one would disable HttpUnit from throwing exceptions due to JavaScript errors. This is necessary because of the on-going differences in the inner workings of JavaScript. Therefore, as a first step, use Snippet 3 to disable these exceptions before the instantiation of the WebConversation object

Snippet 3
// Don't let JavaScript errors trip us up!
HttpUnitOptions.setExceptionsThrownOnScriptError(false);

Putting it all together we create the code in Listing 3. Usually I do all of my development work in Eclipse so I can execute any JUnit test directly from the IDE, however, it can also be executed through ant if so desired. Snippet 4 illustrates a simple ant task that will execute any Junit test classes whose source code is in the relative directory src/java.test and whose name ends with Test.java. This also assumes you’ve already compiled your test source files and they are included in the test.classpath path.

Listing 3
public class CarCruisesTest  extends junit.framework.TestCase{
    public void testGetPAJuneCarcruises(){
        String sURL = "http://carcruises.com/" +
            "cruise_list.asp?month_select=6&" +
            "state=Pennsylvania";
        try {
            // Don't let Javascript errors trip us up!
            HttpUnitOptions.setExceptionsThrownOnScriptError(false);
            // Create the conversation object which will maintain
            // state for us.
            WebConversation conversation = new WebConversation();

            // Create the request object pointing to our URL.
            WebRequest request = new GetMethodWebRequest(sURL);

            // Perform a get request and store results in response.
            WebResponse response = conversation.getResponse(request);

            // Check for valid response code.
            assertEquals("Response code should return 200",
                        200,response.getResponseCode());

            // Check for valid response message.
            assertEquals("Response message should return OK",
                        "OK",response.getResponseMessage());

            // Check for valid response title.
            assertEquals("Car Cruises Online - Cruise Listing",
                        response.getTitle());

            // Make sure there is 1 and only 1 form.
            WebForm[] forms = response.getForms();
            assertNotNull(forms);
            assertTrue("Response should contain only 1 form",
                        forms.length == 1);

            // Make sure the Links are not NULL.
            WebLink[] links = response.getLinks();
            assertNotNull(links);
            assertTrue("Response should contain at least 1 link",
                        links.length >= 1);
        } catch (Exception ex) {
            ex.printStackTrace();
            // Fail the test if an exception is thrown.
            super.fail(ex.getMessage());
        }
    }
}

Since we instruct Junit to format the output as xml we can then feed the resultant xml into the JunitReport task and generate html to make the results pretty. For further information on these ant task please see the JUnit project at sourceforge.

Snippet 4
<target name="test" >
	<mkdir dir="tst-rslts"/>
	<junit haltonfailure="no" printsummary="yes">
		<classpath refid="test.classpath"/>
		<batchtest fork="yes" todir="tst-rslts">
			<formatter type="xml"/>
			<fileset dir="src/java.test">
				<include name="**/*Test.java"/>
			</fileset>
		</batchtest>
	</junit>
	<junitreport todir="tst-rslts">
		<fileset dir="tst-rslts">
			<include name="TEST-*.xml"/>
		</fileset>
		<report format="frames" todir="tst-rslts"/>
	</junitreport>
</target>

Using XML schemas effectively in WSDL design

An excellent presentation from HP giving high level description and reasoning for particular WSDL design strategies. Contains information concerning XML schema design style, schema import within WSDL, XML namespace usage, Web Services versioning, and interoperability.

WSDL Tales From The Trenches, Part 1

Part one of a great and comprehensive three part article series from XML.com detailing issues surrounding WSDL design. This part focuses on WSDL design, generation, statefulness, and implementation design decisions related to the interfacing of web services.

WSDL Tales From The Trenches, Part 2

Part two of a three part article series from XML.com detailing issues surrounding WSDL design. This part focuses on tools, Modular WSDL design, namespaces, and error handling.

WSDL Tales From The Trenches, Part 3

Part three of a three part article series from XML.com detailing issues surrounding WSDL design. This part focuses on data within a web service, covering the import of data definitions (via xsd:include and wsdl:include), schema design styles, and XML namespaces.

Best practices for Web services versioning

A great, in depth article from IBM developerWorks. Provides and details options for managing web service versioning. Includes approaches to web services versioning with UDDI.

SOAP Encodings, WSDL, and XML Schema Types

Article from XML.com concerned with use of a schema from a WSDL.

Best Practices for Web Service Development

Another presentation from HP containing information on the importance of WSDL design, best practices for WSDL design, web services design patterns, development and testing of web services, web services security, and web service reliability.

Web Service Definition Language (WSDL)

W3C WSDL Specification 1.1

XML Schema Part 0 Primer Second Edition

W3C Document which “provides an easily readable description of the XML Schema facilities…”

createTank Attends…

After much thought, I attended the LZA Boot Camp in Baltimore last month (April 23-25) for what boiled down to two hard, tangible reasons:

1. To widen my horizons (and createTank’s) by concentrating on a broader and more business oriented slant toward SOA (createTank has historically focused on research around the implementation questions of a SOA, or software architecture in general).
2. To attain an architectural (and specifically a SOA) credential to differentiate createTank from those that are “architects in name only” (see Vitruvius’ Education of an Architect to be discussed here at a later date). The fact that this credential would come from such an independent and objective organization as ZapThink was quite a convincing point.

I did in fact get what I came for … I saw a review of SOA from a different perspective, and I am now a Senior Licensed ZapThink Architect (Senior LZA). However, I did get more than I expected. Specifically, I found in my notes and “take-backs,” a refinement in some of our positions at createTank. I also met quite a few good Architects and Technologists from across the country and around the world that should hopefully prove to be good friends with which to bounce and share architectural ideas. I’d been looking for a community such as this for a long time now.

Since Then…

I’ve finally found the time to review the notes and complete my internal reports. They really did pack a lot into the three days. The time betwixt has allowed me a good deal of dialogue with other Architects, including our own Larry Liberto, which has further refined the positions and ideas of interest. I should be posting many of our findings and related interesting points here over the next few weeks.

Concerning the refined positions, most are agreed upon by createTank and ZapThink, but createTank seems to have a slightly different take in areas which may prove interesting. This is likely due to our technical and implementation specific background. It might be an over simplification, but we tend to ground our architectural advice from below in our implementation experience, whilst ZapThink tends to support their architectural advice from above with business experience. Of course both methods are legitimate and useful, but they are different. There is a great deal of overlap, as there should be in architecture, but by researching the differences, we may refine our positions and learn more from each other. I’m somewhat amazed at how we’ve come to so many of the same conclusions about SOA and Architecture in general while approaching the problem from such different perspectives. I’d speculate that the common factors are [1] experience and [2] the ability to be honest about that experience. It seems that many groups (especially vendors) let marketing get in the way of that which is best left in its simplest state.

We at createTank have been big fans of ZapThink for a while now as one of only a few organizations out there that were not trying to sell SOA as a set of products, but rather trying to reveal the truth behind its power. I would definitely recommend the LZA Boot Camp to any genuine or aspiring Architect out there with an interest in seeing SOA framed in an objective manner. I’d also recommend it to organizations looking to implement SOA internally, as a vaccine to the seemingly endless vendor sales pitches in store for them.

ZapThink: http://www.zapthink.com/

ZapThink LZA: http://www.zapthink.com/lza.html

ZapThink Architect Resource Center [ARC]: http://www.zapthink.com/ARC-view.html

Next Scheduled LZA Event: Sydney, Australia May 28-30, 2007
Register: http://www.zapthink.com/eventreg.html

As with any SOA implementation or legacy integration, the team wraps the legacy implementation(s) with the chosen SOA technology or framework, adding necessary new functionality alongside. At some point in time after the wrapping takes place, legacy implementations of services/operations deemed to perform insufficiently may be completely replaced by new implementations just as with the regularly described “wrap and replace” method. However, the “wrap and replace” description leaves out the very real possibility of the retention of legacy services/operations which continue to perform and deliver value. These implementations may remain in place working transparently alongside new implementations.

In the illustration, we see two legacy systems (Legacy_A and Legacy_B) and new functionality integrated into a SOA Framework. Within the systems, multiple services or operations are marked in red as candidates for replacement. These are the “squeaky wheels.” Notice that a good portion of the legacy implementations could remain in service indefinitely. This shows the agility that SOA provides, in that the team is not forced to replace the legacy code until they have a “real” reason to do so.

The fact that the legacy implementation can remain around indefinitely brings us to one final point of any good SOA integration, that the system need not be completely replaced or rewritten every major industry cycle. For example, if Legacy_A was written in COBOL in the 70’s, Legacy_B was written in JMS in the late 90’s, and the latest system is written with SOAP over HTTP interfaces, a future implementation in the fictional “Protocol-X” could still retain some or all of the existing implementations without rewrite. This is an important point, because new languages and technologies will continually overcome what we are now implementing.

Sometimes I suspect Bill Gates doesn’t sleep so well at night. Not out of any guilt over his billions or the alleged mediocrity of his product. No, I wonder whether he might actually worry about the competition. Not Apple (though that iPod MP3 player is a killer toy, and I’m cheerfully typing these words on an Apple (AAPL) PowerBook G4). No, I’ll bet Linux and its creator, Linus Torvalds, cross Gates’s mind when he’s looking up at the ceiling late at night.

On the surface, Linus vs. Bill seems to be the ultimate David vs. Goliath contest. It appears to pit the man who cheerfully gives away his code against the guy who ruthlessly seeks every last penny for it. You’d expect Gates would squash Torvalds. Yet they have more in common than you might think. And the final score in their high-stakes rivalry could end up surprisingly close.

MONEY VS. ALTRUISM. For starters, the two face a similar challenge. Even their big brains are puny compared to the wisdom and knowledge spread throughout their organizations. In Gates’s case, it’s a huge, publicly held company. In Torvalds’ case, it’s a loosely connected but increasingly powerful network of software developers. Both men must find ways to motivate people to work together so knowledge can spread and have maximum impact on improving software quality.

Microsoft (MSFT) uses money to motivate. And no doubt about it, that’s a powerful incentive. But others exist. The community of Linux users and developers is held together by pride and the thrill of working toward a common goal of a universal, free (or at least relatively inexpensive), elegant, bug-free or bug-resistant alternative to Windows, the world’s dominant computer operating system.

Can the volunteers who work on improving Linux outperform employees dreaming of stock options? That’s not to say Microsoft employees are motivated only by money. They, too, take pride in their work. Disdaining monetary incentives entirely would seem to cripple Linux and reduce it to a charitable organization. But charities work wonders. They can build a religious community or raise a barn or build a habitat for a neighbor.

Look at the progress Gates’s personal foundation is making against malaria. Honda (HMC), I’m sure, would trounce the United Way’s attempts to design and build a car. But I wouldn’t necessarily expect Honda to do a good job at running a school for the blind. With some causes, passion and pride can outperform money.

GEEK FERVOR. Designing software may be such a cause. A lot of people are passionate about creating an alternative to Windows. In some cases, the desire to see Windows’ dominant position threatened is its own passion. As a 21-year-old living at home, Torvalds created Linux in 1991 in Finland. He offered it for free to the world and made the source code available to anyone who wanted to alter it—as long as the tinkerer was willing to make the new additions available to the public as well. The result is a product embraced with religious fervor by the geek community and even penetrating the mainstream, running servers and other hardware.

Yet the rivalry is defined by more than motivation and incentives. Does Torvalds or Gates have more resources at his disposal? Gates, right? But that answer assumes that money is the most important asset. Even if money trumps idealism as a motivator, Torvalds has a bigger team—the millions who use Linux and continue to tinker with it. Potentially, he has more brainpower on his team.

Torvalds has another advantage. His organization is less organized than Microsoft. It’s really a disorganization. At Microsoft, Gates is the head honcho. Torvalds is just Linux’ gatekeeper. He’s not really in control—he’s called the project leader, the guru. That may appear to be a disadvantage. But remember the problem that every organization’s leader faces: The team’s smartest member, even if he or she is nominally in control, is vastly more ignorant than the entire network of people who compose the organization.

CREATIVE CHAOS. Being disorganized can actually leverage that knowledge more effectively than a command-and-control hierarchy. Innovation must rely on creativity generated by the mass of folks underneath. In a dynamic system, trial and error is a powerful force for change. A bottom-up system with a gatekeeper can be more innovative than the hierarchical system over which Gates reigns. It can generate a lot more trials, and a good gatekeeper can throw out the errors.

You would think being the head honcho allows Gates to plan. But Torvalds rightfully revels in not planning. He’s counting on the marketplace’s judgment of Linux and the wisdom of his disorganized organization as a better strategy. He may be right. And while Torvalds and Linux have recently faced legal issues about whether Linux might have some proprietary code embedded in it, that distraction is dwarfed by the time and energy Gates has devoted to battling the U.S. Justice Dept. That antitrust case clearly diverted resources away from innovation and making sure his organization was operating at top efficiency.

While Torvalds is a threat to Gates, Gates seems to be little or no threat to Torvalds. To hear Torvalds talk about it, he’s having fun as Linux’ guardian. His challenge is merely that of being an effective shepherd to a vast flock of very creative, un-sheeplike sheep. Regardless of the marketplace’s final judgment, Torvalds probably sleeps a lot more soundly than Gates.

This article first appeared on the Business Week web site.

Reprinted with permission of the author Russell Roberts.

Russell Roberts
Professor of Economics
J. Fish and Lillian F. Smith Distinguished Scholar at the Mercatus Center
Department of Economics
4400 University Dr.
MSN 3G4
George Mason University
Fairfax, VA. 22030

roberts@gmu.edu
http://www.invisibleheart.com

Research Fellow
Hoover Institution
Stanford University

Features Editor
Library of Economics and Liberty
http://www.econlib.org