David Herron's Blog

An open quality team

It's been awhile since I last blogged here, I apologize for being so quiet but I've had quite a lot of things to think about. I want to kick off regular blogging with one of those things ... namely what would a quality team look like in the open source world. I know there are many open source projects that have quality efforts such as the unit testing (test-first development) that is so popular nowadays. But it seems that teams dedicated to quality are rare in the open source world.

An open quality team doesn't have the purpose of owning any code, but it may end up owning some code as a side effect of what it's doing.

What an open quality team owns isn't code, but instead the quality assessment of a given product. That is, what are the user requirements for the product, how can an open team measure how well the product meets those requirements, how can an open team measure safety and reliability of the product, etc.

This model can be applied to any product. An open quality team could form around a closed source product like Coca Cola, for example.

So long as the quality assessment of the product is conducted in an open manner does it matter whether the product the team is assessing is closed- or open-source?

Comments

• Interesting post David. I have been thinking a bit about quality in open souce too, on and off. I think that quality teams would be very useful for most OS projects, but getting participants might be difficult. Most developers like to do new stuff, to feel that they are increasing their competency and doing cool stuff. Fewer people want to work with stuff that (they THINK) is easy and/or boring, like comments, documentation, testing.

  Still, another motivational force is to create something of high quality, that stands the test of time, so it might be possible to find enough people with a passion for quality to create teams like that. I for one, would be interesting in participating in something like this for java.

  When it comes to creating teams for closed source products, there is nothing that can stop you I guess, but I think it would be even harder to find participants. Most open source projects are grateful for any assistance and, I think, would be disposed to quality advice if it was presented in a friendly and informative manner. I think corporations would be much less inclined to listen to outsiders. Before acting on the advice, the corporation would have to solve questions like - "Could a competitor possibly have subtly influenced this group to give us harmful advice?", "Are we sure the stuff they give us is completely covered by the open source licences, or do we open up ourselves for later litigation or claims of ownership?". The possibility that the corporation rejects the input that the participants have produced with hard work would lessen the appeal to join. Also, if you give to an open source product you have the sense of a joint ownership, you can immediately benefit yourself from what you have contributed, this is not guaranteed to be so for a closed source product.

  If a company paid the group, the appeal to join might increase again, but then within the group you risk getting conflicts - should the money be split evenly, or should those who contribute more hours get more, and if so, who do you get an honest measurement from all participants? It might be easier to just create some more formal type of "economic association" or small company rather than trying to have an open team working for a closed source product company, in my opinion.

  Posted by: larswestergren on February 07, 2007 at 12:39 AM

• nice idea, BUT :) Some observations:
  quality assessment is a pratice promoted by burocratic models like CMM-x The quality of code in the OSS is guaranteed by the quality of the developers. Usually a OSS is done by high-skilled professionals, and to find a quality team able to verify the work of these smart geeks is not so simple.OSS is usually based on the idea of release first, fix bugs first that means an OSS is not suposed to be released ready for production.
  XP is based on the quality of the people and not based on the quality of the processes - and XP is the base of the major OSS projects.

  Posted by: felipegaucho on February 07, 2007 at 01:40 AM

• The businesses which use the software have an incentive to pay for a quality team. I am sure they exist today. Their efforts are no doubt fed back into the products as bugs, feature requests, issues etc.

  I think as open source moves into the business realm, providing functionality for the enterprise end users, so these teams will become more important.

  I would imagine moving from individual heroic efforts to dispersing quality testing across many organizations would be more effective and speed up verification and validation.

  Posted by: aronsmith on February 07, 2007 at 12:41 PM

• I suppose thinking about the general case .. creating an quality team for any product .. is a bit of a distraction from my day job (leading toward opening up Sun's Java SE team to the open world) but it's a fascinating thought. As you say it would be rather hard to get a traditional corporate management team to accept quality input from the public. Heck, one of the thoughts that fascinates me about watching Java SE become open source is whether/how/if/when we will be able to bring Voice of the Customer information into Sun's management decisions for the commercial JDK product.

  For Java one key item is, I think, that here at Sun we don't know how you guys have written your applications. We do a lot of thinking about how to validate quality in Java SE, and expend a lot of engineering resources in this direction. But no matter what we do we are not 'you', nor do we have 'your' applications, nor your data, nor your environment, etc... so we're going to be missing out on important test scenarios that only 'you' can do.

  And, uh, felipegaucho, are you trying to say that Quality Engineering cannot be done by highly skilled professionals, or that Quality Engineering cannot be done by smart geeks??

  As a card-carrying smart geek who has been working in Java Quality for nearly 9 yrs, well... We have a lot of smart people in the team. Ensuring Quality for the JDK is much much much more than the stereotypical point-and-click sort of QA that you might expect for a typical GUI application. The user interface for the JDK is the Java API's so to properly test the JDK you have to write programs.

  Posted by: robogeek on February 07, 2007 at 01:50 PM

• I've been trying to think of analogue's already existing to an 'open quality team' related to a closed product. And then I realized, I've been participating in exactly such a mailing list.

  I'm a fan of electric vehicles and am happy to report that even though the EV's from the major corporations were all murdered in infancy by those major corporations.. that EV's are available from other companies. One of them is an around-town vehicle from ZAP named the Xebra. It's by no means of the imagination a vehicle to take on the highway and use for road trips, but it will easily handle the typical around-town driving such as the grocery store and other shopping, or non-highway commutes, etc.

  The owner community for this vehicle is rabidly fanatic about it. It helps that the typical EV owner is rabidly fanatic in the first place. But perhaps this would be one required attribute for an independent open quality team to form around a closed product.

  On Yahoo!Groups we have a mailing list, named Xebra_EV, which has been running for several months, is very active, and has been critical for exchanging information among Xebra owners across the U.S. and even with the management at ZAP. Also at xebraworld.com is an owner-driven fan site offering testimonials and an independently produced owners and tinkerers guide. Further ZAP has responded very well and has taken all the effort the owners have put in, and turned each item into changes and improvements to the vehicles.
  

  Posted by: robogeek on February 07, 2007 at 02:02 PM

This work is licensed under a Creative Commons License.