Code Type as an alternative to the 20 percent requirement

[johnnewton]

Although it is laudable to set a quantitative target of 20% for contribution of open source software, perhaps another approach might be to set the targets based upon the types of software and their reusability by other organizations. A possible classification of source code types might be: Infrastructure, Platform, Controllers, APIs, Models, User Interface Frameworks, User Interface Views, Proprietary Rules & Configuration, and Integrations. Some may be more reusable than others, while some may be more important to protect than others.

Most successful open source projects are primarily infrastructure and platform. In fact, Mike Olsen, the founder of Cloudera, observed that there has been no significant infrastructure developed over the last decade that has been closed or proprietary. Infrastructure by its very nature is designed to support platforms and is inherently reusable by many applications. User Interface Frameworks serve a similar purpose as a platform for front-end applications and may be built using popular modern JavaScript frameworks. If constructed and abstracted well, infrastructure and platform may be more reusable than other types of software. Perhaps the target for these types of software might be even higher than 20%.

Some code such as various models and views may or may not be reusable. Here models and views may be divided into general purpose and domain-specific. There may be targets on general purpose models and views. These might be useful for activities such as managing users, groups and roles or general purpose assets. Making these reusable will make it much easier for applications to interoperate. However, domain-specific models and views are likely to be so specific to an application area, that it would not make sense to make these reusable. The same is true for configurations and rules where less general purpose of these types may be considered secret. There may be a target on general purpose views and models, but an exclusion on domain-specific views and models.

Making integrations reusable, particularly using existing open source frameworks such as Mule or Apache Camel, would also increase interoperability of government systems. However, integrations are likely to be distinguished between whether they are general purpose or domain-specific. The best test of this is how widely used is, how generic the data being integrated is, and how secure the data is. The more generic and widely used, the higher the open source targets should be. However, integrations with highly secure systems, authentication mechanisms or proprietary systems may need to be secure themselves.

I make these comments as the founder of Alfresco Software, which is a major open source project in use in the many agencies of the Federal government. We have been able to observe what works and doesn't work in open source in many sectors, especially government, both commercially and in open source adoption.

[peterbenmeyer]

Good insight! I agree. Case 1: The source code offering user interface on the web is likely to be a good candidate for open-sourcing and often should be built on an open-source framework. Case 2: Source code that manages subject-specific survey response data to make statistical estimates may address oddball problems in the data and implement excruciatingly precise hacks to address them. Sometimes it will often make sense to open-source that too, but I believe case 2 exemplifies of what the post refers to here: "domain-specific models and views are likely to be so specific to an application area, that it would not make sense to make these reusable." If this example is agreeable, it can clarify that abstract phrasing.