Name

Design Around the Water Cooler

Also Known As

I guess you had to be there.

Abstract

Your organization has released a project as opensource. The original developers work in the same office building, hang out after work, and generally interact a lot in the real world. Users and prospective contributors feel left out and alienated.

Examples

An organization has decided that releasing one of its products as opensource is a wise move. This has been justified after considering all of the promised benefits of opensource. With much fanfare, the project is released. After the initial burst of downloads and articles, the momentum as exhibited through the public mailing lists has dwindled. The only action seen on the lists is periodic release announcements, many times followed by lots of questions and comments about the newly available features.

Symptoms and Consequences

• Traffic on the mailing lists is low, and tends to be mostly announcements, not interactions.
• Releases include lots of new features the users did not know about or expect
• After each release, users on the list ask an inordinate amount of questions about features in the new release.
• User suggestions are blown off since other design decisions have already been made, if not publicized.
• Eventually users realize that the supposed benefits of opensource projects are not present in this one.

Typical Causes

The primary cause of this anti-pattern is a well-gelled original team. In normal circumstances, managers would love to have a tight and cohesive team. But a team that is not open to outsiders, particularly those scattered across the globe working for other organizations, will suffer this fate.

Secondarily, teams that exhibit this anti-pattern have no learned to use email and other tools for effective group interaction. This may be a result of the policies and tools used within their organization, or simply due to a lack of need. Many teams carry on just fine through hallway conversations, lunch meetings and run-ins at the water cooler.

The culture of the organization may contribute as a third cause. If the management hierarchy, either directly or indirectly, discourages "non-productive" communication, interacting with the opensource community may be stemmed. A corporate NIH (Not Invented Here) syndrome may also cause the team to not bother looking outwards for design and implementation contributions.

Refactored Solution

The ultimate goal is to increase communication to the point that all material conversations occur in the public forums. One trick for encouraging this is for the manager of the team to not inquire directly with the developers in person, but rather to use the public lists to stay abreast of the progress. Developers should be encouraged to not only send regular progress statements to the public forums but to also discuss future choices.

Benefits

The benefits of solving this anti-pattern are the same benefits of releasing code as opensource to begin with. Projects developed within an open community gain fresh ideas and extra brains critically thinking about options. By not involving the community, these benefits are immediately lost and the project might as well be still closed.

Name

Communicate Using PR Firms

Also Known As

You can't whisper with a bullhorn.

Abstract

Trying to harness the post-media world where blogs are powerful instruments to reach the tipping point, you have your public relations firm reach out, poorly, to the blogosphere.

Example

Your firm is readying your product for an important release. While traditional press releases will garner a typical amount of exposure, a true grassroots or guerilla marketing effort would help create actual sales. You've read Malcolm Gladwell's The Tipping Point and understand a bit about mavens, connectors and salesmen.

Your PR firm goes forth and sends out an inquiry to the authors of many blogs related to your market, asking if they would mind receiving actual press releases from you. The goal is to find a way to seed new things into the viral social network of bloggers.

Perhaps you receive positive responses. Negative responses are probably posted upon the complainant's blog. In general, the effort does not produce the results originally envisioned after a fevered night of reading Gladwell's book.

Symptoms

• You just read The Tipping Point.
• You start a marketing meeting with the phrase "If only we can get in front of the mavens and connectors..."
• Instead of approaching your own current users, you approach a community that you do not currently have solid relationships with.
• You approach a one-to-one conversation with a one-to-many broadcast.
• Your attempt generates one or more negative blog entries within the community you were targeting.

Typical Causes

The main cause of this anti-pattern is that a little bit of knowledge can be dangerous. A lot has been written about epidemic and guerilla marketing. Some success has been created by fooling people into believing they are having a genuine relationship. In the untainted "real world" of viral ideas and memes, the mavens and connectors of the network rely upon real relationships. These are not necessarily close personal relationships, but they are unsullied by any concentrated marketing effort.

These are people who enjoy sharing new and novel ideas that they find value in. Equally, they enjoy discovering ways they can do favors for friends and colleagues.

Once a marketing department or PR firm of a commercial entity enters the picture, the dynamics change radically. The connectors and mavens you so dearly wish to reach have absolutely no relationship with the marketers. While your product may be beneficial and perfectly suited to them, you've broken the unwritten protocol of using the network. It only gets worse if you rely on impersonal bulk mail. Actual people do not have relationships with organizations. They have relationships with other people.

Overall, you are approaching the problem with an ahead-of-the-curve enlightened technique. But the devil is always in the details.

Refactored Solution

Realizing that memes propagate across paths of genuine relationships, the solution lies with the creation of genuine relationships. This does not necessarily mean wining and dining the important movers and shakers of the community (though, free food does always help). It does mean that to approach a grassroots movement, you must start within your own roots. Individuals from your firm need to cultivate relationships with individuals outside of it.

While marketing attempts to reach a wide audience, viral ideas must start close to home. Instead of targeting bloggers with whom you have never interacted, find the bloggers among your current relationships. They certainly might not be as high on the food chain of the blog world, but in a six degrees of separation fashion, that does not matter.

Your own developers and technical support people need to be interacting with your users on a regular basis. They should recognize each others' names. You can seed the network with your own users, some of whom will pass it along until you have gotten widespread visibility.

If you want to branch out to attempt to tap in higher on the network, care must be taken developing these relationships. Have the appropriate people within your organization (definitely not your PR firm) interact with the target bloggers. It is imperative to establish your credentials through useful and knowledgeable contributions.

Encouraging the individuals within your firm to develop these relationships requires effort. Ultimately, you need to have a cohesive message developed by your marketing department. They need to transform themselves into mentors for your technical staff.

Benefits

Doing all of the above, unlike some guerilla marketing techniques, does not rely on fooling people. By establishing real relationships, and contributing to the network of ideas, you are actually adding value. When you participate and truly add value to a community, can expect to likewise reap value from it. Your users will see the difference. Your marketing efforts will be better received. You will build a reputation that long out-lives a PR blitz.

Name

Opensource as End-of-Life

Also Known As

Freedom's just another word for nothing left to lose.

Abstract

Instead of gracefully retiring a product which is past its prime, it's released as opensource and left to wither.

Examples

Over the 20-year history of a hypothetical supply-chain software firm, their product evolved from a DOS application through Windows 3 and on to Windows XP as a single-user application. The firm recently created a web-based version of their software which has seen good adoption, at the expense of the older single-user products. The firm has decided to move the remaining resources from that product onto the more successful product line. It releases it as opensource instead of simply removing it from market.

Since the company no longer has an economic interest to invest in the product, only a bare set of web pages are put online and the software is placed on an FTP site. The marketing departing of course finds the time for one last grandiose press release to be widely reported. Initial reaction is mixed. Some people herald the release of yet another commercial product as opensource, regardless of the details. Others feel that the firm is just exploiting the opensource movement for marketing purposes.

After the hubbub has died down, it becomes clear that the project has no traction. The firm has all but forgotten the project. Occasionally it is mentioned in the press, sometimes as an example of corporate opensource, sometimes as an example of a failed project.

Symptoms and Consequences

• The opensource release is thin, since the company has already decided to remove resources from the product.
• The source is released with a very encumbering license due to concerns by the firm's legal counsel.
• Executives are wary of future opensource strategies, due to the "failure" of the first attempt.

Typical Causes

A product reaches the end of its commercially useful life when a financial analysis shows that the return on continued investment to be lower than alternative uses of the resources. The dollars earned compared to the dollars spent no longer justify spending any dollars. Support costs are too high. Revenue is too low.

With the recent attention on opensource, companies are starting to look for ways to participate. A product that has lost its commercial value to a company seems like a ripe candidate for releasing as opensource. The fear of losing control of a product is lessened as the firm has lost interest in it. Since the future expected earnings for the product are already $0, there's nothing left to lose. Legal counsel unfortunately can always find risks, and they mandates a strict licensing for the code that is released.

Refactored Solution

Instead of approaching opensource as a nothing-left-to-lose proposition, it should be approached with a gain-oriented mindset or not at all. The gain could be money or simply goodwill. But if the product truly has no value, it's best to simply let it die with dignity.

There are several ways to sunset a product as opensource. If the product serves a lower-end market that your firm has grown out of, releasing and honestly supporting the product as opensource would not cannibalize your sales. It would generate interest and goodwill with customers that may grow into your higher-end product.

If the product is your only product and sales are not sufficient to support your firm, the commercially licensed version could be retired into an opensource project to grow a market for a services-oriented business. This is the strategy used by Laszlo Systems with their OpenLaszlo project.

Perhaps your firm has moved into a tangential market, after having your original product become a commodity. Instead of a half-hearted attempt at opensourcing it, you could place it with a non-profit foundation or other independent entity. Since there truly is nothing left to lose with a commodity, releasing without an encumbering license would allow others to truly enhance and extend it, which would still benefit your ancillary business.

In any case, to successfully release even an end-of-life product requires resources. It can not simply be thrown over the wall and thenceforth ignored. If you cannot justify expending any resources on the product after you perform a cost/benefit analysis, then do not release it.

Benefits

By approaching end-of-life and opensource with the appropriate mindset, you can avoid setting yourself up for failure. You can also avoid the bad press that inevitably will follow. Knowing that effort and resources will continue to be required, a true opensource strategy can be explored. Otherwise, you can save yourself the headaches.

Name

Everyone is a maintenance coder.

Also Known As

Hey, don't touch that.

Abstract

When opening the source of a project, the team does not allow outsiders to contribute meaningful changes.

Example

A firm releases a project as opensource under their control. Outside developers begin to adopt the project. Advanced developers start filing bug reports, which get accepted into the code. As time progresses, these developers see places where they feel they can materially add value to the project through new features or other non-maintenance code.

The team, wary of these outsiders, either ignore these suggestions, review the suggestion, but implement the functionality in their own way, or sometimes will apply the change verbatim.

Reporting and repairing bugs is not fun while certainly one benefit of releasing a project as opensource. Initially bug reports may spike as new adoptors dip their toes into the codebase. When these developers submit grander changes for inclusion into the codebase, having them be ignored or rebuffed serves to alienate the potential contributor. Possibly to the extent of not even bothering with bug reports in the future.

Symptoms and Consequences

• All committers to the project work for the same employer. Even as opensource, this still poses an alienating cathedral scenario.
• Patches are seldomly applied. Potential contributors will quickly learn that their work was for nought.
• Bug-list grows faster than previous. Core project members are relying on outside contributors to fix bugs. Maintenance coding is everyone's responsibility

Typical Causes

A sense of elitism is natural within small tight-knit teams. A sense of paranoia is natural from a large corporation with several administrative groups involved in the project (particularly the legal department).

The first stems from pride, where the original developers realize that they have created something cool and are blessing the world with it. This cause is the easiest to solve, typically, but not always. Over time, with education and perhaps some mentoring, these developers will learn how to spot other qualified developers from outside of the firewall to bring in.

The second stems from hubris and risk avoidance. The many internal corporate stakeholders of a project may prevent the introduction of external contributors to an opensource project. The legal department, concerned about intellectual property, produces non-standard licenses and complex contributor agreements that require a notary and a fax machine.

If the newly opened project is only part of a larger suite produced by the company, other product groups can exert undue pressure. Other development groups that rely upon the project continue to view it as an internal project, not understanding that they are now simply users of an opensource project. These groups (through their product manager or the engineers themselves) may prevent the project from accepting outside contributions that do no fit the larger internal product plans.

Refactored Solution

As with many problems, the solution ultimately relies on education and a change of culture.

Elite development teams can stage "interviews" with prospective outsiders they may wish to join the core team. By viewing the recruitment of outside contributors as a human resources activity, they may be able to adjust their mindset towards bringing new people into the fold.

For legal issues, counsel must be advised by the appropriate executives about the goal and strategy involving the opensource project. Given normal corporate guidelines followed by legal counsel to reduce corporate risk, they will naturally be seen as an antagonist towards the opensource project and culture. By providng the legal department with different guidelines for the opensource project, many hassles may be avoided.

Other product teams that still view the newly opened project as an internal project pose the hardest to solve problem. From their point of view, they have lost control of a part they depend upon, and have gained nothing in return. Now release schedules are out of sync, unneeded features are being added, and they can no longer apply corporate political pressure to get their highest priority bugs and features dealt with.

Continual education and management buy-in for the opensource initiative is required. Other product teams' managers must be on-board and not promote internal corporate pressure on the open project's team.

Benefits

While the prevailing opinion is that opening a project can bring in others to help fix bugs (the Many Eyes Theory), ultimately that is a short-sighted goal for an opensource initiative. By concentrating on bug-fixing, there is the possibility of alienating and driving off external contributors.

Those contributors who can do more should be encouraged to. For every 30 people who submit a bug-fix, getting 1 stellar feature-guy is worth the effort of bringing him into the core team. Simply compare the salary of your QA guys to that of your "architects". The external contributors who are capable of adding new functionality to the project, and not merely fixing your developers' bugs, are the people who give you a real ROI on the opensource project.

In addition to the free labor angle, advanced outside contributors can help combat natural corporate groupthink. By not necessarily being immersed within the culture and demands of the project's sponsoring organization, he can bring new previously-unthought-of ideas to the project.

From the external contributors point-of-view, even if they are not selected to join the core team, simply seeing one or a few other outsiders as part of the core will prevent alienation. In fact, this would encourage these others prospects to contribute even more, in order to prove their worth.

Name

Ignore Established Tools

Also Known As

That's not how we do it around here.

Abstract

Ignoring the commonly-used established tool set will quickly alienate potential community members.

Example

A firm decides that opening one of its products would benefit the community and also provide a nice marketing boost from the resulting press releases. The executives sign off on the initiative. The legal department scrubs the code and applies a useful license. The engineering department removes offensive comments from the code. And eventually, it is dropped into CVS and a press announcement is flung far and wide. After the initial announcement, traffic to the project site spikes, and then falls off, leaving a ghost town.

The anticipated flock of developers and users simply never materialize. Awareness of the project exists. The firm feels that the technology is robust and useful. But no one seems to be joining in. A survey of potential users and contributors results in learning that they find the project hard to work with on a superficial level. It doesn't match their experiences with other opensource projects. Being used to having certain facilities and tools used within opensorce projects, they shun projects that use non-standard tools and facilities.

New projects represent a learning-curve with regards to their own technology. Potential community members will not also climb a learning curve of new development tools.

Symptoms and Consequences

• Use of a non-standard build system, inappropriate for the target community. Using make on a Java project, for example.
• Use of non-standard documentation systems. Using MS-Word for documentation in the source repository instead of HTML or possibly PDF.
• Use of non-standard revision-control tools. Missing web-view of repository and/or email notifications of changes.
• Use of non-standard testing tools.

Typical Causes

• Unwillingness to change the project's culture upon release into an open community.
• Effort spent on non-engineering activities before release. Executive decisions, legal input, and marketing efforts take precedence over engineering preparation.
• Not realizing that opening a project targets a new market with different needs and requirements.

Refactored Solution

• Survey the larger opensource community the project will be joining.
• Adjust the build-system to that acceptable by the target comunity.
• Manipulate documentation into a form expected by the target community.
• Set up, learn, and use the development tools used by the larger community.

Benefits

By spending engineering effort before releasing the project into an open community, a higher probability of success may be achieved. The marketing goals of opensourcing a project will be better met, of course, by greater acceptance of the project within the community. Adjusting the project to accomodate the standard tool set expected by opensource users and developers may be seen as an expense without a direct benefit when viewed on the small scale, and likened to rearranging the deck chairs on the Titanic. But integrating seamlessly into the larger opensource community is a requirement if an opensource initiative is to be successful.

By accomodating the existing set of expected tools, the firm will engender significantly more goodwill than simply throwing the project as-is over the corporate firewall. Less accusations of the initiative being simply a marketing hype activity will surface. Contributors will not constantly be reminded that the project is the outgrowth of a firm that doesn't truly understand opensource. Instead, contributors will see the firm as enlightened and truly beneficial to the opensource community.

Related Solutions

• Ignore Established Methods (forthcoming)