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:
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.
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.