I have recently been programming the SEXTANTE bindings for ArcGIS (they are not finished yet, since I am having a very busy week with other priorities, but I will resume working on them next week and hope to have them ready soon) and working with the ArcGIS API has made me think a bit about how the propietary software model can somehow be an advantage for a certain kind of developers. I am not, of course, saying that propietary means better (I will always prefer open source to propietary), but there might be a few things that we can learn from propietary software developers and some positive side effects of not sharing your source code.
This all comes from the following fact: being a complete ignorant about ArcObjects and the ArcGIS API, I have been able to create the corresponding SEXTANTE bindings from scratch in less time than I needed to create any other bindings before. That means less time than the gvSIG bindings (an application that I knew pretty well), and way less than the OpenJUMP or Geotools ones (both of them softwares that I had worked with before, at least once).
This is basically due to the clean, well designed and perfectly documented API of ArcGIS, which, along with the additional Eclipse plugins, makes it very easy to develop new plugins and extensions for the software. Unfortunately, open-source GIS lack that kind of APIs, or they are, at least, not so carefully designed, documented and implemented. Although other factors might concur, I am convinced that the propietary nature of ArcGIS is a decisive one to have such a powerful and developer-friendly API.
Let's put it this way: ArcGIS developers want other developers to create plugins for their software, so they have to provide an easy way of doing so. However, they cannot let you see the source code or their application, so they have to make sure that everything that an external developer might need to create his plugin is correctly exposed through their API. The API has to, somehow, replace the source code for certain development tasks. On the other hand, open-source programmers are aware of the importance of developing a correct and well documented API, but the availability of source-code might act as an excuse for sloppy or unfinished APIs, assuming that, if an external developers misses anything in it will search the source code and try to find whatever he is missing.
That doesn't necesarily mean that open-source APIs are not as good as proprietary ones, but, while an open-source software, even if it lacks documentation and has a poorly designed API, it is still useful (albeit frustrating) for a developer, the same circumstances will render a proprietary software useless in term of development. That alone should encourage proprietary software developers to create and document practical and useful API (and we all know that this is important, since that is not always a nice and rewarding task...)
Once again, I insist that I am not praising the proprietary model, but just trying to find its benefits and trying to learn from it and apply it later to my open-source projects. I believe that everyone can teach us something and there is always something to learn from everyone. And, although I am not one of those who see proprietary software as an enemy, even enemies can teach you a few valuable lessons and it is not a good idea to ignore them. Quoting the much-missed Rage Against the Machine: Know your enemy :-)