Community and "Fake" Open Source Projects

In today's market where open source developers have realized they need to make money on open source, these are some of the schemes that have been developed. Each one brings with it a unique brand of community-killing problem.

The lack of open user documentation keeps people from trying your application. You can post all the demos and screenshots you want; unless it is a simple application no one is going to get very far with your application without this resource. This keeps the number of people that are going to go to the next step and pay for support or services related to it artificially low. Additionally, an increasing number of projects are now adopting wiki-style or commentable documentation; these beneficial community building features not only improve your documentation for free, it makes users much more comfortable with your software, which makes them more comfortable asking their staff to buy your services.

Without an open bug tracking system, when people who would otherwise be evaluating your software cannot find an easy way to search and report on bugs while tracking the status of their fixes, they are going to realize your whole development process is closed. Then they ask themselves, why don't I go try another package instead? With a closed bug resolution and development process, any benefits they may have seen in your open source product is lost which will lead clients to seek alternative open source solutions, or even turn to a proprietary solution which they will perceive as being on the same standing as your product since you just threw away your advantage.

Some projects just have woefully inadequate developer documentation. This problem keeps new developers from joining your project which is going to cause the eventual doom of your project unless you have plenty of money to pay developers; but wouldn't you rather keep that money? Equally as bad, when you charge for your developer documentation, no one develops for your application except you and your high dollar already-subscribed clients. This may sound like a good thing on the surface, perhaps you don't want amateurs mucking with your codebase, but in reality you are locking out innovative change from those very people, and it defies the reality that most companies start small and build up. These smaller companies don't have the money to add onto your application, as they can't see the documentation, when they start up; this inane model ends up locking you out of new up-and-coming clients who go to your competitors or start their own projects instead.

Without access to your up-to-date work in progress, it is impossible to tell what the current status of the program is. This makes it impossible for anyone to give you patches that actually work against your latest codebase, so you waste valuable time porting these patches. Many developers won't even bother sending you a patch without such access; the lack of feedback and no ability to test against the latest code eliminates the benefit of contributing patches in many developer's eyes.

There isn't anything legally wrong with making money using one of these ideas. The open source model certainly allows you to do so. But each of these problems, especially when stacked, chip away at your community and make your product far less valuable overall to potential customers and in the end will lead to the community building around your product and making you irrelivant, and perhaps more importantly to you, pennyless.