Introduction

I believe that Open Source involvement can actually benefit a corporation, even if the heart of their strategy is proprietary. The real trick is to evaluate both open source and proprietary solutions on a level playing field. Each should be able to stand on their own in this evaluation against your goals.

If corporations take a look at both, I believe they will find that the answer is probably a combination.

Community

Seems like an odd topic when discussing software development. But, when you evaluate open source software, you have to evaluate the open source community. After all, you are going to depend on that community to enhance the open source software you choose to implement.

Take a look at this article from CIO magazine:

"Who are Those Guys?"

In the article, they say:

"Turns out these people have real jobs—58 percent of the open-source community is made up of professional IT administrators and programmers (with 11 years of professional experience, on average), and 30 percent of them will have to answer to their bosses if they don't write open-source code. That's right: Open source is their job, according to a recent survey of 678 open-source developers that was conducted by The Boston Consulting Group (BCG). "

Another quote I Find interesting (emphasis added):

"The most successful open-source projects are those that solve a problem that the community's biggest constituency—IT admins—are encountering in their day jobs. "To form a successful open-source community, you have to have an overlap between people who want to solve a problem and people who have the skills to solve that problem," says Dan Frye, who leads a group of 250 IBM programmers who work on Linux full-time."

But I would generalize this to say that the most successful PROJECTS (open source or otherwise) are those that solve a business problem. A lot of software projects never come to production--an amazingly large number--if you believe the statistics.

Lots of things on the open source sites are not worth much. But those that solve one or more genuine problems should get the attention and the resources.

For a commercial enterprise to be involved in the open source movement, they should have a problem to solve. Of course, for a commercial enterprise to get involved in any software project, they need a problem to solve.

The point I am trying to make here is that open source projects are not different from any software project undertaken by a commercial enterprise. They need to be evaluated by whatever metrics an organization uses to assess a project. The difference is in the allocation of resources to support an open source project and the addition of resources from outside our organization.

So what should your development strategy be? First, get involved in the open source community. Chances are that if you put your development resources into an open source project, you will be able to influence its direction. Given this, you can then place resources on any priorietary elements to your project. Chances are because you are gaining leverage from the open source community for the bulk of you effort, you will have additional resources to devote to the proprietary elements of your project or you will have to devote fewer resources to the development effort.

Don't expect the open source community to work on what are really proprietary elements of your project. Generally, in projects, the bulk of the elements of the project are common to projects across the world. For example, database access, web display, data transformation, etc. Choose those elements to develop through the open source method. Keep those elements which are unique to your business in your own shop.

How can you do this? How about developing a pluggable architecture for your project. You can develop the bulk of the project through the open source community and then provide your own plug in for those elements which are unique to your project.

You might consider the use of Service Oriented Architecture (SOA) for your project. Because you are developing descrete services, you can develop or obtain common services through open source while maintaining the unique elements for your specific development.

Updated: 12-Aug-2004

perl

This is my web development scripting language of choice. I should note that I am not a perl biggot and am always open to other, better languages for development work.

Read more . . .

Fit the Pieces

The key is to find the appropriate mix of open source and prioprietary software to maximize your return on investment (ROI). It is like making an intricate puzzle. You need to make sure that all the pieces fit. Your development strategy should include consideration for maintenance of your systems as well as development costs. Like a puzzle, all pieces need to fit to make the complete picture take shape.

This development philosopy means that open source should be considered on a level playing field with proprietary software. It also means that you need some idea of what the complete picture is in order to fit the open source pieces to make that complete picture.

-- Updated: 7/25/2004