Open Up to Open Source

Both companies and the open-source community can benefit from partnerships

In the corporate world, frequent releases are a great way to include clients in the entire software development process. Clients can evaluate progress, deviations from requirements (or requirement deviations) can be identified early and addressed, and the "big-bang" delivery associated with the Waterfall method is avoided. Iterative development requires a more mature software process, but clearly one a corporation could develop.

COLLABORATING THE OPEN SOURCE WAY

In the open-source world, virtually everything is done in a distributed development environment. Communication takes place in the form of email, logged IRC conversations, design documents, and white papers, so information must be written down. People can find out why decisions were made and what still needs to be done. The same should happen in corporate development teams. The important thing is to have useful documentation. In some open-source projects, these are automatically generated from the source by tools such as doxygen or javadoc; other times they are formal design documents. Find something that works for your team and use it consistently.

Configuration and source management are essential; people who have never met need a way to share the code base. In open-source development, configuration management becomes second nature. If you want people in Germany to see your changes, you need to put them into CVS. If the changes break something, someone else will roll them back.

In less-mature corporate environments, developers may find it easier to cheat and simply copy the source onto a floppy disk or email it to a coworker. However, this process falls apart quickly. Keeping file versions in order becomes impossible, and work is often lost or duplicated. Your development team must reach a certain level of discipline to make any process work, and source management is an essential part.

Because open-source developers work when and where they want to, a way to bring the whole system together is imperative. This integration is accomplished by the well-established practice of subsystem partitioning or less formally, an established API. Typically, someone (often given the title "maintainer") is responsible for approving changes committed to the source repository and will not allow established interfaces to be broken or circumvented. If no central authority is watching, the team of developers working on the code base will be more than happy to let you know if you break an interface, either syntactically or semantically.

Even though corporate teams tend to work from a centralized location, they must have the same source-police mentality regarding their code. The project will still be developed in pieces (components) and must fit together at the end. The software architecture will generally be expressed in terms of frameworks and patterns to be applied projectwide. These rely on adhering to subsystem interfaces to maintain consistency. Your project architect can act as the maintainer during code and design reviews. The important thing is that someone, preferably everyone, is watching out for your interfaces and subsystem boundaries.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

Despite what the naysayers might tell you, open source is here to stay. It is quick moving, very adaptable, and bursting at the seams with talented developers doing what they enjoy. Several well-known companies have decided that a partnership with the open-source community makes sense, contributing back as much as they benefit by way of hardware, software, or employment. In addition, smart businesses make themselves familiar with open source's practices and internalize them. This often results in developers contributing to open source on their own. Everybody benefits, and it becomes a win-win situation for the industry as a whole.

Dan Pilone [dpilone@blueprinttech.com] is a component framework engineer at Blueprint Technologies and an active contributor to the open source community. He has released several of his own projects and is participating in ongoing development teams. Currently he mentors Blueprint clients on OOAD/Architecture.

RESOURCES

Prepared text of remarks by Craig Mundie, Microsoft Senior Vice President, "The Commercial Software Model," The New York University Stern School of Business, May 3, 2001: www.microsoft.com/presspass/exec/craig/05-03sharedsource.asp