In every business—and even in open-source projects—there comes a time when demand outgrows the status quo and the time for change arrives. In the rapidly evolving world of technology, this is all too relevant. Robert Kennedy stated, “Progress is a nice word. But change is its motivator. And change has its enemies.” Unfortunately, it is sometimes necessary to take a step back to make way for progress, and this can make the process even more difficult. Human nature resists change, yet logically everyone knows it’s necessary. The key is to make the process as smooth and painless as possible.
The Business of Open Source
The Business of Open Source
Open Source: Making Success Your Biggest Problem
Open Source: Step Back for Progress
Open Source vs. Business
It’s often obvious that a project needs to change. The question is really how to do it. Will the old project just be given a face-lift, or does it need to be thrown out completely to make way for something new? Will the new project be thrust upon the users, or will it be slowly fed to them over time? Retiring the old amid the flurry of a new release is quick, but sometimes a gentle approach is better because it gives users time to adapt and accept what’s to come instead of forcing it upon them. In this case, incrementally migrating the new into the old is an effective approach. This is a common approach among software companies, providing users with upgrades and new features over time to allow users to learn and grow with the software. It generally means more initial work on the developers’ end, but it aids customer retention.
More on Open Source
ABC: An Introduction to Open Source
Free Code for Sale: The New Business of Open Source
The Enterprise Committer: When Your Employee Develops
Open-Source Code on the Company Payroll
To provide users with a project worthy of change, developers must first go back to the beginning: Take a look at how the project was initially constructed and evaluate if that is still the most effective and feasible option for current needs. In the case of a software application, this may mean reconsidering the programming language. What was it about that programming language in the first place that made it the best solution? Is it still viable? It may seem drastic to rewrite a program in an entirely different language, but it may be the only solution. If this is the case, be prepared for resistance. Backward compatibility will be compromised, and users won’t like that, but if it really is the only solution, remain firm. Even if users are presented with change gradually, some will balk. Complainers will be vocal, so be prepared to respond. Make sure that decisions are well founded so a strong defense can be provided. It may not be a popular choice, and some users may leave, but if the right decision was made this will all be resolved in time. Most importantly, keep users informed: Be open, explain the need for change, and openly accept criticism and questions. Provide a road map so a clear goal is established and everyone understands where they are headed. Use every medium available to inform. Publish articles and blog entries, and make announcements on the company website well in advance to give users time to prepare.
On the home front, make sure staff are prepared. Whatever course of action is chosen, it will involve work, and a lot of it. Long hours and monotony may ensue, and staff may feel discouraged by negative comments from the user community. For open-source projects, this is the time to turn to contributors. The open-source community is overflowing with members who are more than willing to share their talent and expertise. Rely on both them and full-time staff to share the workload. This is where the work involved in establishing an active open-source community around a project pays off. This is also a perfect example of how an open-source project in desperate need of improvement can gain from a related business dedicated to its well-being. Take advantage of all available resources to work through this time of change, and eventually the naysayers will quiet down.
Change may have its enemies, but they are quickly silenced by progress. Seize this opportunity to once again evangelize the project. Give speeches, participate in interviews, revamp the website, send out press releases—anything to get the word out and generate interest. This may have been done at the project’s inception; however, doing so again will revitalize the project’s image and renew its recognition. Let people see where the project has been and the progress it has made. Be honest and admit that sacrifices were made along the way, but demonstrate that the results were well worth it.
Stagnation does nothing but rot and destroy. Be the spokesperson for change and help others see that true progress often comes after a period of regression, when mistakes of the past are recognized and learned from, to the benefit of all. Without progress, improvement would never be realized, and without the change that spurs progress, nothing would be accomplished. Silence change’s enemies by proving that taking a step back is sometimes the best strategy for improvement.
JT Smith is a renowned open source guru and the president of Plain Black Corp., the developer and distributor of the WebGUI Content Engine. He speaks internationally on topics related to Web content management.