By Freddy Mallet on February 16, 2011 » tags continuous inspection, functionality, languages, platform »
13 comments
After an initial attempt that ended up posting on what was accomplished last year, time has now come to discuss the plans for Sonar in 2011 and the associated roadmap !
In 2010, Sonar has progressively become a “must have in software factories” as are already Jenkins, Jira, Nexus or Subversion for instance. With Sonar, a quality platform can now be considered as a commodity which can be installed and used by everybody with only little investment whether it is time or money. We will still focus our effort in 2011 to increase the value of the platform and make teams capable of continuously assessing and reimbursing their technical debt even easily than today.
Read the rest of this page »
By Evgeny Mandrikov on April 15, 2010 » tags hudson, maven, open source, platform, plugins, users »
2 comments
This is sometimes a bit frustrating, when you are contributing to an Open Source project, to have doubts about who your users are… really. Not knowing them might lead to not understand their needs and therefore not being close enough to deliver value.
Despite the fact that we are always ready to answer questions on the mailing lists, the Sonar team wanted to be sure it knows well enough its users and their experience using the platform. That is why we recently made two polls and today I would like to share their results :
Read the rest of this page »
By Olivier Gaudin on March 31, 2010 » tags functionality, platform »
no comments
Codehaus has been officially accepted into Google Summer of Code 2010. Based on the great job done by Ben Walding previous years, we expect that several projects get funded at The Haus this year.
Ben has open a page for Codehaus projects to propose ideas they wish student could pick and develop. We have proposed 3 ideas that we think are interesting challenges for students and a great addition to the Sonar platform :
Read the rest of this page »
By Freddy Mallet on January 27, 2010 » tags open source, platform »
2 comments
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 !.
By Freddy Mallet on June 25, 2009 » tags platform, plugins »
4 comments
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.