In our recent open source developer survey we asked, what are the TOP FOUR characteristics considered when selecting a component? And since components are the building blocks used when creating an application, selecting the right one is an important choice.
Not surprisingly, the most important characteristic for the selection are the features and capabilities provided by the component. After all, if the component doesn't fulfill your requirements then why use it?
Choosing the Right License
What characteristic do you believe comes next? You might be surprised. The second most important criteria was licensing according to 67% of the respondents. Most components available out there are open source licensed and it seems that, by now, the open source model has been around long enough that users know, they have to choose the right license. For example, if you ship proprietary software or bundle it on a hardware device you sell, you probably want to avoid GPL. Otherwise you will have to GPL license all your code. In my circle of developer friends, it seems to be common knowledge that a few firms that did not comply to their license obligations have ended up in lawsuits. As such the license of the component can be a blocker for specific component usage, just like missing features can be.
Is it Compatible?
The next important criteria was compatibility information (63% of responses). Given that upgrading components in large, complex applications can be a big task, this makes sense. However, in many cases I have seen, this is often used as an excuse to avoid an update.
Upgrading components is no longer as difficult and complex as it used to be. Given the great tooling available to developers with refactoring support in IDE’s and others, my choice would be to upgrade often and regularly, rather than only when required. From my experience, the more often you do it, the easier it gets. You hear this mantra, when it comes to releasing often, but I think it also applies to component upgrades. What do you think?
The rest of the important criteria was only mentioned by less than half of the respondents. In my opinion, some of these are rather alarming. I would consider some of them to be more important than compatibility.
Is that Component Vulnerable?
For example, only 43% of the respondents said that they consider known security flaws as one of the top four criteria. Personally, I attribute this to the fact that information regarding security flaws is not readily accessible to many developers and therefore does not rank high on their priority list. At Sonatype, we are already addressing that challenge with our Nexus and CLM solutions, ensuring that component information is readily available (i.e., security vulnerabilities, license risks, version popularity, version age, etc.).
Policies that Help and Hinder
Shockingly, only 33% considered “conformance with internal policies” an important criteria. I attribute this to two situations. First, as a developer myself, I don’t really like policies that tell me what component to use -- especially if I have little influence on the component choice, or in the worst case disagree with the component choice entirely. Policies are often out of date and can sometimes prevent you from using a newer or better component.
Second, getting a policy updated often entails a lot of paperwork or other manual activities that distract from core development work. Many developers I have spoken with have also relayed that if an internal policy exists only on paper and is not really enforced in the build - They don’t feel obliged to comply with the policy.
The good news for these scenarios is that Sonatype CLM makes it easy to enforce a policy in your IDE, your CI build, and your release process. And it also makes it easy to administer and update the policy. Additionally, you have all the relevant data to create a good policy right there in your tools!
Give Me Choices
Another important characteristic selected by 42% of survey participants was “popularity vs. other components of its type”. For example, should you use commons-logging, log4j, slf4j or logback for you application logging needs? Apache Shiro, Spring Security, some other JAAS implementation or something simpler? What about dependency injection - Google Guice, SpringFramework or Dagger?
These decisions are typically complex and they involve a lot of questions, including:
-
What other components do you use?
-
What are the performance differences?
-
How active is the community supporting the project?
-
Is the component mature enough?
-
Is the project actively maintained?
It’s Time to Concentrate on Coding Again
All these and many other characteristics can influence your component choices. And while your decisions will change over time, the more information you have readily available to you when making these choices, the better off you will be. Just remember, you can now rely on more than just word-of-mouth or simply going the easy route and selecting the same component you used last time. Both our Nexus and CLM solutions put more information at your fingertips, so that you can concentrate on coding again.
