The specifications and tools built within open source communities usually have numerous contributors, all of whom have different perspectives on the software. This approach lends itself well to building comprehensive solutions for a lot of the normal problems that would otherwise have to be custom developed through a proprietary approach.

Open specifications are constantly in development. Unless your company is actively engaged in developing these specifications and tools, the upgrades and features are added independently of your company or product. This means that you do not need to devote engineering resources to upgrading the product with new features. When a new version is developed, the teams implementing the product simply need to revise their tools based on the requirements set forth by the specification. Even though you do have to allow for some development time in this approach, the issues related to security, features, and upgrades have already been solved and outlined within the specifications.

The supporting community and documentation for open source software is often extensive, providing many supporting samples and use cases.

The solutions are not custom built for any one container. Even though specifications like OpenSocial define methods for integrating only the portions of the specifications that you require for a particular implementation, these pieces still encompass a lot of use cases that you may not have needed for a custom container or application solution.

The specification upgrades are usually bound by community voting procedures, where everyone has a voice and can vote on which upgrades they see as the best features. This process can be a benefit at times, but it can also mean that not all the requested features make it back into the core specification.