Some more thinking about open source projects

Wow - any time you mention open source, you touch a nerve don't you...

First off - just because I work for Microsoft doesn't mean that I am against open source.  In fact, I work in a team that builds class libraries and shares the source with the community so I am actually all for the concept.  Now I am not trying to solve any issues at the OS level so I am not going to debate Windows vs. Linux.  Let's think at a smaller scope for now.

Suppose you are creating a useful library for .NET development.  It is the "Foo" library.  Here is the question...

How do you collaborate with the world in the development and evolution of the "Foo" library while exposing the quality in an objective way and insuring that the quality of "Foo" is trending upward (getting better over time).

When I talk to developers I often ask if they use libraries like this and I find that few .NET developers (<10%) make use of these type of solutions and one of the primary reasons is that they are unsure of the quality.  I believe that if we can find a way to address this concern we can take great ideas, collaborate on them and produce useful libraries that people feel comfortable using.

Here are the questions I think we need to answer:

  • What would an objective measure of project quality be?  Unit tests? Code coverage? Responsiveness of the community?
  • What would it take for you to feel comfortable with using a "Foo" project?  What do you look for?  What does your employer require?
  • If you were in charge of the "Foo" project, how do you insure that contributions from the community don't hurt your project because of quality problems?

I don't pretend to have the answers to these questions, I'm just honestly asking how we can address them.  There are two other issues that loom large in this arena as well and they are licensing and dependencies, but I'll leave those for another blog.

Comments (9)

  1. cthrall says:

    Mozilla is one large project that IMHO is of very high quality (I switched to Firefox a year or so ago and have been very happy with it).

    They’ve created some build/test harnesses for exposing the state of the project. Maybe if there is a unit test suite that is exposed to the public engineers (and their managers) would feel more comfortable using the tools.

    Here’s the Mozilla example:

  2. Responsiveness of the community will be a real world measure of the code quality.

    I use a good number of "Foo" projects and I assess them on the ability to provide the feature(s) that they were designed for.

  3. Ron Jacobs says:

    No bad experiences? No bugs found in the "Foo" projects? No unaswered posts on message boards?

    I suppose if the project is simple and straightforward you don’t have too much to worry about.

  4. cthrall says:

    I’ve used open source fairly frequently in development and production systems. In my experience, I’ve found the quality in proprietary and open source solutions to be very similar.

    With regards to message boards, I don’t know what I’d do without Google, again both for open and closed source. I don’t usually ask questions since in almost all cases somebody else has been there first.

    Look at the PHP documentation site for an example (see, for instance) of community involvement. Each page lets users add comments, which turn out to be invaluable…"I found a bug, the workaround is x y z," or "here’s some sample code."

  5. Scott Allen says:

    A plus for me is if Foo has an open, archived, and searchable forum for community involvement and support. A Wiki is ok, but I generally feel more comfortable if the Wiki / FAQ supplements a more interactive forum.

    Seeing Foo in other projects, either commercial or open, would be a plus (but I realize everyone has to start somewhere). A searchable issue tracking repository is a plus.

    As for the issue on ongoing quality, a test suite which includes unit tests is a big plus.

    From a business perspective I want to know the licensing up front. Outside of licensing everything else boils down to mostly technical issues for development to eval.

    Turn offs and warning signs:

    No obvious place to go for support or to contact a responsible party.

    Projects that look stale. No posts, news, or obvious activity.

    Code issues, like poor API usability, reflect on quality. If FxCop finds critical problems, then there is a problem.

  6. Marcus Baker says:

    For me a tutorial is number one. If time has been taken to care for the first time users, then the chances are care has been taken elsewhere. Also acceptance tests or failing that unit tests. I use them as the documentation to find out what’s really going on.

  7. Barry Gervin says:

    Commercial software is not synonomous with quality. But I think an effective technique if your audience is developers is to expose (as open source) unit tests for your library. In fact, I’ve had clients pay me to write unit tests for 3rd party libraries – including some of the PAG ones. I’ve even go as far to create unit tests against the .NET Framework base class libraries. Whenever I’m trying out some new class and I need to play with it to fully understand it, writing an NUnit test is just as quick as writing a console application….plus I get the huge benefits of adding that to my repository of tests. It also acts as documentation if somebody asks me for some snippets on using x in the framework.

  8. After a few days of reading and tinkering, I’ve implemented a system for using Enterprise Library (EL) to handle ASP.NET page-level authentication. In my system a User class facilitates authentication by username/password or a user token. An AuthPage clas

Skip to main content