Share via

Recommendations for corporate teams developing Community Based Open Source projects

  • Article

 

As I said in my earlier post, our corporate team develops tools that we want to turn into Community Based Open Source projects. The projects are developed as closed source. Occasionally, the requirements were open and discussed with community members before development began.

 

When we decide a project is ready to be “opened”, we release the source and binaries to a web site. We maintain the open source software and accept community contributions. We will act as project owners until we complete the transition to a Community Based Open Source project by transferring the project’s ownership.

 

Our team has learned many lessons about the open source world since we released our first power toy to an open source site. Since that first release, we have had bug reports, feature requests, and code contributions. My suggestions below are based on our team’s experience. I hope you find my thoughts useful.

 

If you intend to create a Community Based Open Source project:

  1. Hone your people skills! Perhaps, the most important thing we learned is that each member of the team has to interact with the community. This is unusual for developers in a corporate team. You will have to deal with a wide variety of people with varying levels of skill and experience. In other words, you will be in a situation similar to that of a manager of software developers. It can be difficult for software engineers to make that transition since many of us are introverted sorts of people.
  2. Do not get discouraged! There’s a rule of thumb in open source projects that says “90% of the work will get done by 10% of the people”. There are many reasons behind the phenomena. I don’t really want to take the space to discuss them here. Do not be overly concerned about low percentage of participants from all downloads of your project. Consider your project successful if it is used and you have any community participation. If nobody downloads it or nobody sends any feed back or all the feedback is very negative, go back to the drawing board!
  3. Expect to be flexible! It may be more difficult to schedule releases in community based projects. You will have to adapt and improvise a lot. If you have not already adopted agile project management techniques, now is a good time to consider it.
  4. Think about bug reporting during the project definition phase. You should at least verify that the open source web site you intend to use provides mechanisms for bug reporting and project discussions.
  5. After you go open, respond to bug reports quickly. If the report does not provide enough information for you to debug the problem, ask for more information. If the bug report is adequate, you should at least acknowledge receiving the bug report. If the bug report includes a suggested fix, thank the submitter and put verifying the fix on your list of urgent things to do.
  6. Think about testing during the project definition phase.
    1. Write a simple test document that identifies the test tools you will use and outlines the automated tests. All manual tests should be described in enough detail for someone else to execute the test and decide whether it succeeded or failed.

                                                              i. Concentrate on defining “functional” tests that show the code does what you intended it to do when it is used appropriately.

                                                            ii. Include some “end-to-end” tests that cover the basic usage scenarios.

                                                          iii. Include some “negative” tests which make sure your code handles basic error conditions gracefully. Negative tests are especially important for user interfaces since manual input will frequently cause errors.

    1. Consider code coverage analysis while planning your tests.

                                                              i. If there is a free code coverage tool that accommodates the language or languages you are using for development, it is recommended that you use it and test your project thoroughly enough to get about 80% code coverage.

                                                            ii. Until you approach 80% code coverage, your project is probably too bug ridden to be useful to people who use it. Nothing will kill your Community Based Open Source project faster than frustrating your users!

                                                          iii. You may have to implement additional tests to reach 80% code coverage.

    1. Automate your tests as much as possible. This will make repeated testing due to bug fixes and community contributions much easier. You will need a test harness and other test tools including a code coverage analysis tool. Remember to use freeware!
    2. Develop unit tests as the code for the project is being developed. This is a great opportunity to do Test Driven Development. You write the test first and then write just enough code to make the test pass. As you implement additional tests for the feature, you add just enough code to the project to make the new test pass. When you have created tests for all the requirements and all the tests pass, the related part of the project is complete.
    3. Require unit tests for community contributions whether the contribution is a bug fix or a new feature. The test case for bug fixes should include the conditions that generated the original complaint. In general, unit tests should come from the community member making the contribution.

  2. Open Source means open everything! When you release any version of your project (alpha, beta, or whatever), release the requirements documentation, test plan, user documentation, and design documentation along with the code.

  3. Alpha versions: When you are preparing a release a new version of your project, you may have difficulty getting near 80% code coverage from your tests. If that happens (or you are not using code coverage tools), make an alpha release of your project. Most people understand that an alpha version will be buggy. Many will be willing to use the new version anyway to help you debug it. Many people debugging a project is one of the primary benefits of going open. So, take advantage of it. If you make an alpha release:

    1. Identify the features which are not well tested
    2. Provide an easy way for users to report bugs on the alpha version
    3. Add test cases that reproduce the conditions in a bug report to your test suite, if possible.
    4. Fix bugs that are reported (and reproducible!) as quickly as you can
    5. If your test suite includes a new test case for the bug, the test suite will verify the bug fix is actually fixed. In future releases, the same test case will act as a regression test to make sure the bug remains fixed.
    6. Release an updated alpha version as quickly as you can. Many open source projects release weekly at such times. Some release updates daily or even more frequently. Obviously, it takes some effort to prepare a release. If the effort required to release your project is minimal, you might release after each bug fix. Otherwise, you might want to fix several bugs before expending the effort to release an updated version. It will always be a judgment call which weighs the effort to release against the importance of the bug or bugs that have been fixed.

Comments

  • Anonymous
    February 09, 2007
    Holy smokes!  Wow, I am really lined up with this.  I'm weak on coverage (but strong on minimizing branches and variations), but this really fits.  I may have declared beta earlier than you suggest, but that is really in the context of one user and we'll see.  And I won't go public on SourceForge until I satisfy your points.  What great timing for me!   Thanks again.

  • Anonymous
    February 13, 2007
    John, our only SDET (tester) on the team, has written a couple of blog entries on what we've learned

  • Anonymous
    February 20, 2007
    John's blog postings on testing open source projects where recently picked up by Mary Jo . Not bad PR

  • Anonymous
    July 21, 2007
    On our one-year anniversary of our power toys release, I gave a Microsoft Engineering Excellence Talk

  • Anonymous
    July 21, 2007
    On our one-year anniversary of our power toys release, I gave a Microsoft Engineering Excellence Talk