|
I agree. Two thoughts from many from reviewing these issues some time ago:
1. APIs should be well defined, documented and open. The guts of the "engine" can remain closed. Where accepted standards are present, they should be made available (note this allows for extensions or enhancements). [All obvious perhaps, but these aren't always true...]
2. Where possible and realistic, companies ought to pledge that if they cease to maintain development of a product, that either the product be sold onto someone who can maintain it whilst maintaining the same service and fees for users or its source code be released to the public for the community to maintain as they see fit.
I'd like to think that for most people documentation of the points at which they interact with the software and being able to give feedback are more important than access to the source code.
Point 2 avoids products dying unexpectedly that might otherwise be maintained by the community. My understanding is that this is what has happened with Web Objects (?).
With these two in place, I suspect two of the more practical needs of "openess" are covered. I'm open to (civil!) comments about that.
|