Corresponding from O’Reilly’s 2008 Open Source Convention in Portland, our colleague Sam Nguyen noted provocative trends in the emergent (and relatively young) philosophy and practice of open-source software design. Among them:

1. Cleaner, tighter software with smaller subroutines & more loosely-coupled components; processes designed to run as short as possible and a move toward DRY-ness (I added the “ness” on the end, not Sam) where DRY means Don’t Repeat Yourself.

Why? Cleaner software increases readability, reduces errors and is easier to maintain, making collaboration among coders easier and reducing maintenance time.

2. Daily testing of software to catch new errors in coding and prevent old ones from coming back.

Why? Automating tests gives you an internal rhythmic feedback loop that lets you know when something is wrong.

3. Releasing software early and often. (Eric S. Raymond, The Cathedral and the Bazaar)

Why? Putting products out there early, with a feedback loop to drive refinements, speeds the development of robust, enduring goods and services.

4. Open source applications entering the enterprise environment through the back door. IT professionals are looking for (and finding) ways to make open source software drive business objectives and create competitive advantage. (Think of how personal computers were first used in businesses — not introduced as company-sanctioned devices, but brought in by individuals who needed the functionality.)

Why? Without compromising security or reliability, more and more resourceful tech pros are finding ways to say, “Here’s how” instead of “Here’s why not” (and they’re not finding those solutions from vendors; they’re finding them in peer-to-peer exchanges of open source code).

5. An increased premium on usability and human interfaces that measure the quality of an application by its user-friendliness. In short: High usability trumps high coding technique.

Why? Sam says this is something that may not be immediately obvious to geeks, who often find that they would rather tweak algorithms rather than design good interfaces. What’s increasingly clear is that programmers who can do both are in high demand.

Sam:

There appears to be a movement in software development methodology toward simplicity, cleanliness, and minimalism (think 37 Signals, the Google homepage, the Agile Development Manifesto) . It seems to be more of an evolutionary, organic approach than some of the older, more monolithic methodologies out there (Waterfall, IBM). This is something that may work very well in the Open Source community…I wonder how it would work in other scenarios.

We think Sam’s observations raise important questions beyond the programming communities.

• How could simplicity, cleanliness and minimalism contribute to a smoother sales or accounting department?
• Why not implement tests that measure the quality of the product every day?
• How could placing heightened value on usability and human interfaces enhance incoming communication conduits?
• How could leaving some back doors unlocked streamline collaboration and increase innovation — especially among people who don’t work in the same physical space?
• How could rapid prototyping and testing improve processes and products before they’re delivered — and how could ongoing testing find and fix problems before they turn into customer complaints?
• How could uncoupling processes and unbundling products increase efficiencies and generate sales by providing workers and customers with what they need or what they can afford rather than what our companies would prefer to offer them?
• Could realigning people and assets to reduce duplication and deliver more lead to greater value?
• What would it cost to ensure that operational orthodoxies don’t block the way to what’s next?