Your argument for open sourcing your product is simply "why not?" rather than "why" :)
But enough generalities. Here are a couple reasons in favor of open-sourcing your project:
- Free bug fixes. If a bug is affecting a number of users, then some users will at least feel like they can do something about it. That is a very tangible benefit because there's no faster way to lose a customer than if they discover they can't use your product for some mostly-trivial reason after they dropped $50. But for desktop apps, it's more likely that a user will just tweak the product slightly to suit them. They might even have fun with it.
- Free marketing. Even though the tech crowd is not nearly as massive as the consumer audience, techies are probably the most valuable type of customer. They will help build a community around your product by answering other users' questions, for example. And what better way to attract people like us than by offering us more control?
That said, the primary reason is to help people. When I was first getting started with programming, it would have helped me tremendously to see how an "industry-strength" game engine worked, for example. I personally like the idea that a novice might cut his time spent on learning down by half or more. All they need are real examples to tweak and to build upon. So if there aren't any reasons to keep source code secret, then I'm going to share it in the hope that it will inspire someone, somewhere. How cool would it be to have access to all of Facebook's source code? And Facebook wouldn't be endangered by that at all, because its value is in its content, not its source code.
After writing a book about an open-source project, I get a lot of questions by e-mail. My usual answer is "Ask the mailing list."
This is much better for everyone -- the answer becomes google-able, and they can draw from the experience of the entire community, not just me.
I couldn't agree more that it's very beneficial to thoroughly document your code. If you're curious, here's a snippet I wrote yesterday to tokenize a .X geometry file: http://pastebin.com/f74646d17 .... that type of aggressive source-code documentation is how I write all my code. My process is basically to write each function's entire algorithm in English, then to write the actual code. The result is "free" source code documentation. I also don't lose any productivity doing that. Just the opposite... I'm certain that it's more productive to write each function in that way, because I am constantly spotting bugs while writing the pseudocode that I otherwise wouldn't have caught until runtime. It's very easy to "misspeak" in C++. It's not a very good language for communicating concepts. But English is, and so by describing the same concept in both languages, you end up simplifying your ideas more than you would by just "speaking in one language". The result is usually a much simpler algorithm.
Unfortunately, the misconception that "writing comments makes you less productive" combined with the (valid) argument that "good code documents itself" makes this style of writing source code less than popular. But oh well, at least I can benefit from it, and maybe someone else will try it.
That said, the fact that such extensive documentation is necessary (or at the very least nice) suggests to me that you'd be better off using a cleaner, more powerful <http://www.paulgraham.com/power.html>; language that: (1) documents itself to some degree through more elegant syntax (2) takes care of low-level tasks that clutter and confuse otherwise clean code (resource allocation, memory management, etc.) and (3) requires less code to do the same thing, which means fewer lines to document.
There are a bunch of great languages out there that are far more powerful (in terms of abstraction) than C++ or C. Haskell, Lisp, ML, F#, to name just a few. You might consider checking some of these out if you haven't already.