Modularity in proprietary and open source projects

In successful proprietary software projects components are carefully owned and managed. A component owner’s perspective is that there is a set of responsibilities which are the remit of that component and no other. So the owner takes care to encapsulate the data and function of the component. Ideally, and to a large extent in practice, when a new requirement needs to be satisfied, component owners negotiate and divide up the responsibilities necessary to satisfy the requirement. Responsibilities are assigned according to the remit of each component, although these remits may be extended or refined over time.

Accessing another component’s implementation detail is frowned upon and known to impact reliability, serviceability, and maintainability. Since each component’s objectives are ultimately subservient to those of the project, component owners try hard to hide implementation detail from other components. In particular, component owners are motivated to reduce the cost of servicing old releases.

The motivation of developers on open source projects is markedly different. Of course, they too are concerned to deliver components with useful function which are in themselves reliable and which can be evolved in the future. However, they have limited resources and each component has a potentially large set of users who will not necessarily agree about the precise remit or objectives of a component. So it is in the interest of an open source project to keep components sufficiently open that they may be extended by other projects to produce variants.

A common experience in open source is that, as soon as some implementation detail is in any way declared ‘private’, a developer from a related project will complain and argue persuasively why they need special access to the implementation detail. Since there is no overriding set of objectives and open source projects are not responsible for each other’s code, the path of least resistance is usually taken and the ‘private’ declaration is removed. If the implementation detail later changes and projects depending on that detail are impacted, then no blame is attached to the project that made the change. The attitude is that the other project got what it deserved. The onus is therefore on ‘consumers’ from other projects to select the type of dependencies they wish to create and to manage these dependencies appropriately.

The Eclipse open source project faced similar resistance to declaring implementation details private. So they added an Eclipse-specific convention of using a ‘x-internal’ directive to plugin manifests to flag certain implementation packages as ‘internal’ to the module that exports the package. These packages may still be used by other modules, but the fact the packages are internal is explicitly acknowledged.