Software Development Communities: Size Matters

When it comes to comparing software development communities, it turns out that size does matter. When comparing two programming languages, most of us focus on things like syntactical differences, supported paradigms (such as object-oriented programming), deployment issues, performance, and many other factors. However, for large enterprise development, and especially for large enterprise development with many unknowns or risk factors, the size of the development community for that particular language can be an important consideration. The same argument can be made for frameworks, libraries, and other development tools.

While newer languages and frameworks with smaller development communities certainly have their advantages, there is no denying that some of their appeal can sometimes be traced to motivating factors such as the Magpie Effect, resume-driven development, Emperor's New Clothes Effect, Lemmings Effect, and other such motivators. Perhaps the most significant downside of working with these newer languages and technologies with smaller development communities is the corresponding lower amount of documentation and assistance that is available. For smaller projects, this is often not all that problematic. For large, long-term projects, however, I sometimes think we developers could be a little more understanding when "they" (management or clients) are somewhat concerned about using the fancy new language, framework, or toolkit. Regardless of whether one likes C, C++, Java, C#, or one of the other such languages, I think we can all understand how management/clients might be more comfortable going with one of these languages on a long-term, large project.

The flavor of the day may be great for a certain type of task for which it was designed. This in no way means that it is best for everything and I understand a manager's or client's hesitation to be one of the first to select a language that has been largely unproven in long-term, enterprise projects. The manager or client knows that any problem encountered with development using something like Java will be able to be dealt with in some way because so many large enterprise projects have used Java already. Furthermore, Java has been around long enough and been used by enough developers that many best practices have been developed. The forums are filled with experience from developers all over the world who have used Java. Even in areas where Java may not be as nice as another language we might compare it to, there are usually well-documented work-arounds for the deficiency.

The significance of size is not limited to programming languages. Most developers and managers are likely to be much more comfortable using the Spring Framework than using a framework that I might start tomorrow. Why? Because whether one likes Spring or not, one understands that Spring is very pervasive in the industry, has been vetted and used by a horde of developers, has significant SpringSource-generated documentation and third-party documentation, and has many forums filled with advice and answers to tough questions.

I'll use Flex as an example of this from my own career. When I began using Flex two years ago, it was new and exciting. The only drawback was that I could not always find the answers I was looking for immediately. I had gotten used to Google searches giving me answers for anything I asked in the Java world and had to get reacquainted with the Google message "Your search ---- did not match any documents" for some of my Flex queries. That was actually part of the excitement as I was able to blog on several tricks and nuances as I discovered them and provide original value for others to use.

Two years later, I still enjoy using Flex, but some of the newness is gone. The Flex development community feels many times larger than it was two years ago. While I was able to easily keep up with at least reading the headlines of any new Flex blog posting or article two years ago, there is no way I can do that now. I rarely see the "Your search ----- did not match any documents message" when Googling on Flex. The positive of all this, of course, is that it is much easier today to find one or more blog postings or articles covering most of the problems one might encounter with Flex. The much larger Flex development community makes it much easier to find answers to Flex questions and problems.

More developers in a given community implies more people to answer questions; more people to write articles, books, and blogs; more people using and testing the software of the given community; more people learning from experience and developing best practices; more people requesting bug fixes and improvements; and more people sharing new ideas. These advantages are especially desirable for large, long-term projects because it is those projects that can least afford to make a bad decision from which retreat is difficult. In these cases, it is understandable that managers and clients feel more comfortable going with a programming language, framework, or toolkit that they know many others have found success with. It doesn't hurt to know that there are developers available with those skills as well.

The size of the community of a particular product is less important when that product is used in such a way that retreat is easy if needed. For example, a toolkit that is only used for a small part of a large project might be easy to justify regardless of its small community because it is easily removed or replaced.

The size of the community is especially important in the open source world. I'm not referring simply to the active developers on the open source project. Rather, I am including all who use the open source product, who write about the open source project, who file bug reports against the open source product, etc. In my opinion, size of the community is especially important to open source because this community size directly relates to many of the advantages associated with open source.

Open source is often touted as advantageous because of advertised benefits such as potentially being tested by more people in more diverse and realistic environments, potentially quicker problem resolution, being subject to potentially greater code review, etc. However, these advertised benefits can only be realized if the community around that open source project is large enough to provide the greater use and testing, greater problem resolution, and greater code review. If I run a one-man open source project and I am the only user of that project, it is doubtful that the product enjoys any of these advantages compared to any serious commercial/proprietary/closed source competitor.

Even programming languages, frameworks, and toolkits with large communities started out with small communities. This reminds us that there is significant merit and potential associated with many products that currently have small communities. I am not saying in this post that we should only use products with large communities. What I am stating is that we should be more understanding when managers or clients prefer products with larger communities and that we should always keep in mind size of the community as one facet of our decision-making process regarding selection of a programming language, toolkit, framework, or other piece of our software development. There are many factors to be considered when selecting a particular product, but size of the community often deserves to be one of them.

My final thoughts are of appreciation for others who do take risks with products in smaller communities to help those communities grow and of my own satisfaction from occasionally playing with these products with smaller communities. While I often understand and even agree with managers or clients that we need to use the safer product with a larger community in our large enterprise projects, I also must admit that there is a thrill from playing with the latest gadget (language, framework, or toolkit). As with so many other parts of the software developer's life, I try to balance these and use them appropriately.