Sonar is known as being the open source platform to evaluate and report continuously on source code quality. Its basic role is to evaluate the code technical debt that slows down productivity. Of course, several factors can lead to a productivity slump and poor code quality is only one of them.
Another one is the effectiveness of the Continuous Integration process. CI practice is directly inspired by Lean Manufacturing practices and the main goal is to “Create a continuous process flow to bring problems to the surface … as quick as possible”. When the Continuous Integration flow fails, this is very good feedback to hear : “Hey guys, stop the line. You first need to fix this issue : compilation failure, unit tests failures…”. But if the CI flow fails too often this is also a bad news as lot of time is spent fixing the problem and not developing new features.

Read the rest of this page »

When used out-of-the-box, Sonar is a code quality radiator accessible by everyone at anytime. Like for JIRA, Hudson, a post-it dashboard or any other piece of the development toolset transparency is a key success factor for adoption. So, by default in Sonar, anyone can access any project under continuous inspection and navigate through it.

But of course, there are situations where securing Sonar is necessary. Let’s imagine for 2 minutes a consulting company that does development for customers and wishes to allow those customers to follow their own projects in Sonar. Since the company has many customers, it is necessary that group of projects can be isolated to make sure each customer only has access to his own projects. Prior to Sonar 1.12, this was only possible by having one instance of Sonar per customer.

Since Sonar 1.12 there are services available in the web interface to handle this and to cover the following use cases :

• Secure a Sonar instance by forcing login prior to access to any page
• Make a given project non accessible to anonymous
• Allow access to source code (Code Viewer) to a given set of people
• Restrict access to a project to a given group of people
• Define who can administer a project (setting exclusion patterns, tunning plugins configuration for that project, …)
• Define who can administer a Sonar instance

All those use cases can be implemented through the Sonar web interface and will take effect immediately. The way security is handled in Sonar is pretty classic as the security policy is based on the following three concepts : user, group and role (global or by project). Let’s take the example of the “Project roles” page available at project level :

Three roles are available at project level : Administrator, User and Code Viewer. Users and/or a groups of users can be associated to each of those roles to get the required permissions.

User and group can be first created through the “Users” and “Groups” services available in the administration configuration section. Here is the screenshot of the “Groups” service :

That was authorization, let’s now talk about authentication. By default, user authentication is done against the Sonar DB (user table) but an external authentication engine can also used : OpenLDAP, Microsoft Active Directory, Apache DS, Atlassian Crowd … Three identity plugins already exist : two open source LDAP Plugin, Crowd plugin and a commercial one Identity Plugin. They all use the public Sonar authentication extension point.

To conclude, it is possible since Sonar 1.12 to easily implement a robust enterprise security policy. Those new functionality have been done with no impact whatsoever on Sonar users who do not want to activate security and want to keep full transparency.

SonarSource, founded more than a year ago, is a Swiss company that leads the development of the Sonar platform. Obviously Sonar and SonarSource are really tight together : Sonar would not be where it is today without SonarSource, but the other way around is also true. Like any company making business around an Open Source product, we often get the question on what Open Source means for us and what is our real commitment towards it.

The short answer to this is a single word : LGPL. The is the license we chose from inception of the project instead of an ordinary GPL license. Why ? Because we believe that to make Sonar an extensible platform rather than just a tool, we need a license that fits both Open Source community and Commercial companies needs. To make sure people are going to invest in a platform, it should belong to its active users. With this choice and to keep its leadership on the platform, SonarSource has therefore committed to continuously invest in Sonar.

The longer answer refers to the idea of an Open Core by Jason Van Zyl. Jason describes what are his four principles and we fully adhere to them :

• The Open Source product you provide to users must be great: the Open Core should stand on its own as something truly useful without any additional commercial add-ons. The software must perform well in a production environment.
  
  This is so true that many Sonar users don’t even know the existence of SonarSource




• The Open Source product you provide should go through an ungodly amount of testing and QA. Testing and QA on the Open Core are the cornerstone of quality and should not be reserved for commercial versions of your product.
  
  The Sonar core is covered by about 1′300 unit tests and 150 integration tests (most of them are selenium tests) which are executed by two continuous integration server. Of course we run Sonar on Sonar on a daily basis and we do performance profiling before every release. SonarSource’s plugins are extensions of Sonar, not a kind of professional packaging : they fully depends on the quality of the core.




• The Open Source product you provide should be architected such that all commercial features are plug-ins to the Open Core.
  
  The Views, Master project, PL/SQL and Identify plugin are fully based on Sonar extension points and nothing more.




• The Open Source product you sell should have completely open pricing. If someone cannot clearly see what your pricing is and what the difference is between your open and commercial versions, you likely have a predatory and opportunistic pricing model
  
  I believe it is the case.

With the the adoption of LGPL and the respect of those four principles, you can definitely Come in, we’re open !.

A change of year always gives to teams an opportunity to look back and measure what was accomplished… and then to start thinking of what the new year should be made of. I thought I’d share the output of the Sonar team retrospective.

At the end of 2008, very few people knew Sonar. The platform was made of a small community of early and eager adopters who were supporting the product strongly by giving feedback, asking for more functionality, making suggestions and testing new versions. It was also made of Sonar 1.5 that, looking back, was the foundation version of the platform. From this version, here is what was achieved in a year :

• A dynamic development activity on Sonar core with 7 major releases since 1.5.
• The transformation of Sonar from a tool to an extensible platform with more than 20 extension points.
• More than 30 open source plugins have been build to extend Sonar core using those APIs, and more that are not open source.
• the number monthly downloads has been multiplied by 10 during the year from 300 to 3,000.
• Sonar has been given a heart called Squid that makes Sonar much more than an integration tool. Several metrics that do not exist elsewhere are calculated by Squid.
• More than 4′000 emails exchanged on mailing lists and 1,000 Jira issues created.

So after all this, what could be an exciting challenge for 2010 ? We have set ourselves 2 very ambitious objectives for 2010 which should make the Sonar community continue growing :

• Design analysis : we like to say that there are seven technical axes of code quality analysis (we call them the seven sins of the developer). Sonar currently covers sixth of them and the last one is for us the most important one with unit tests : Design & Architecture. Sonar 2.0 planned for February will start covering the 7th axis with O.O. metrics like LCOM4, RFC, DIT … cycles detection and DSM at package and class levels. All those information will be of course provided by Squid. Moreover, an architecture rule engine should quickly appear after Sonar 2.0.
• Multi-languages : last but not least, give a real go at other languages. By the end of the year, we expect that plugins are available to cover properly : Java, PL/SQL, Flex, C/C++, Cobol, PHP and maybe more :-)

Here is a part of the program for 2010. I have now to leave you to start working on this as I think I will not have much spare time this year !

There have been numerous debates around commented-out lines of code (line or block of code that was commented out at some point) and whether they should be left in the code or taken out. The outcome of those debates is almost systematically that they should be taken out sooner rather than later : in the Sonar Team, we generally consider than later means after code check in.
Here are the main reasons why old commented-out code is an abomination :

• It always raises more questions than it gives answers
• Everybody will forget very quickly how relevant the commented code is
• This is distraction when going down the code as it stops the flow of eyes
• It is a bad SCM engine : Subversion, CVS and Git are really more trustworthy !
• The simple fact of understanding why code was commented out in the first place can take a lot of time

But the worst of all is in my opinion the fact that commented-out code appeals commented-out code, similarly to The Broken Windows Syndrome ! All this was reinforced by Uncle Bob a few months back in his Clean Code Tip of the Week #7.

Read the rest of this page »

During the last few months, Sonar has definitely become the leading Open Source Platform to manage Java code quality. The objective to democratize access to code quality is becoming concrete.
However when analyzing source code, quality is only one aspect of things. The ultimate platform should be able to handle Quality, Security and Architecture. Sonar 2.0 will take care of Architecture with a DSM and several valuable Object Oriented metrics.
What is the plan to handle Security ? Technically speaking, there is no difference between a quality rule and a security rule. They both consist in writing a piece of code that analyzes an Abstract Syntax Tree (AST) or the bytecode depending on what needs to be done.

Read the rest of this page »

No one from SonarSource could attend the event. However we are proud that Sonar is going to be represented there by a company who we share at least 3 values with: Agility, Open Source (GreenPepper) and Human values. This company is Pyxis !

At the same time, the first version of the Greenpepper Sonar plugin has been released. Go and meet the Pyxis’s team at Agile 2009 : they are really nice people, I am sure they will give you a demo of GreenPepper / Sonar… and maybe a Sonar tee-shirt ;-).

A lot of work was done during the last 40 years to enable the emergence and formalization of models in order to evaluate software quality. SEI Maintainability Index and ISO 9126 standard (9126-3 for source code quality) are the results of several decades of research. Those models bring value in the field of software analysis and they should be respected for that. When discussing source code quality, I often see people referring to those models as bibles. They do not make their own judgment and sometimes simply forget to use the models with common sense.

About a year ago, I met an expert in charge of implementing a commercial tool to evaluate source code quality. After he explained to me the advanced model used to calculate metrics on usability, reliability, maintainability… I asked him a naive question : how do you integrate Continuous Integration (CI) and Test Driven Development (TDD) practices or even latest emerging object oriented metrics in your quality evaluation process ? The answer came straight back with a smile : “that is a developer thing”. In other word, the model is the model and should be taken as is.

But what’s about evolution of practices, improvement of build infrastructure and new languages ? Should it simply be ignored when evaluating the quality of source code with a model that was established 15 years ago ?

I have been working on Sonar for several years now and I do believe in the product and do see the value that the platform brings to development teams on a daily basis. But increasing the quality of development does not simply consist in analyzing the source code quality.The approach we prone is very much Return On Investment oriented. At any time, you should know what is the next action you are going to take base on ROI. Now that I have implemented a solid development infrastructure including a CI engine, now that TDD is part of the culture of developers, now that functional traceability is part of my process, I can focus on improving quality of the source code and have a real action plan.

We call it : walking before you can run !

A few weeks ago Michael Marth, who runs dev.day.com (Day’s developer portal), asked us if we could put together our impressions on the code quality of Apache Sling using Sonar. We thought it would be valuable to share the result of this exercise with the community.

Apache Sling in a few words

“Apache Sling is an innovative web framework that is intended to bring back the fun to web development. It uses all those nice cool and new technologies that make up a state-of-the-art framework. This is Apache Sling in five bullets:

• REST based web framework
• Content-driven, using a JCR content repository
• Powered by OSGi
• Scripting inside, multiple languages
• Apache Open Source project

Read the rest of this page »

You already know Sonar as an enterprise tool to analyze and manage code quality of a projects portfolio. We claim, for very good reasons obviously :-), that it is easy to install and easy to use. Currently, it covers Java and PL/SQL languages.

As a tool, Sonar is more and more often compared to commercial products such as Cast Software or Metrixware for instance. Having said that, if I had the choice, I’d prefer Sonar to be compared to Kalistik (commercial product) that better fits the market evolution and needs.

All this is great, but as you might have realized already, Sonar is more than a simple out-of-the-box product : it is an open source (LGPL) platform to manage code quality, i.e. the foundations on which the community has already started to build new floors. Our aim is that Sonar becomes to quality management what TCP is today to network applications : the central component to go further and faster. That’s our new dream since the command “mvn sonar:sonar” is available :-).

Here are real life examples that support the idea of Sonar being a platform:

• Let’s say you have built a commercial tool (PC-Lint, Simian, SAP ABAP Code Inspector … ) or an open source one (Testability Explorer, Crap4j, Clang Static Analyzer…) or let’s say that you think a new axis of quality analysis would be more pertinent. By developing a plugin in Sonar, you kill two birds with one stone : you immediately have access to a large community of users and you benefit from the built-in functionality (TimeMachine, trends, consolidation…)
• You manage a consulting company and are building a package around quality. By building this package around Sonar, your client gets basically the tool for free and what they are going to pay for is what you have to sell : your expertise on quality

I believe that code quality management is going to become a commodity in the medium term as is continuous integration today; and I do hope that Sonar is going to play a central role in this democratization move.