There is a lot of discussion around how free and open source software (FOSS) can be used in a scalable business and what business models support using FOSS. This is often captured in questions about how one makes money when one gives the product away for free. Likewise there are concerns raised over how IPR rights in standards organizations need to be managed to enable FOSS implementations. A few definitions help tease apart the discussions so various paths through become apparent. For this discussion I’ll assume the actors are all well behaved, i.e. no plagiarists, submarines, or trolls.
FOSS and Business
A business creates a marketplace and manages products through a pipeline. FOSS adds interesting new tools to the product development and customer engagement toolkit, but FOSS doesn’t fundamentally change the nature of the business. The easiest way of thinking about this may be to recognize that companies sell products (and services) to customers, while FOSS projects develop software collaboratively in community. This doesn’t mean that companies don’t mix with communities, nor that products can’t related to projects, but these are separate things with different engagement processes.
Companies may use software from external FOSS projects as part of the business offering, or they may publish components from their product space under FOSS licenses, and further they may develop communities of users and/or developers. There are well-understood ways for managing each process: i.) developing product channels, ii.) licensing FOSS projects, and iii.) developing technology user/developer communities. Successful companies understand that these are separate functions and how to manage each process to support the other two.
FOSS and Standards
The nature of any tension between FOSS and standards is in their relationship.
A. If there is only ever one true FOSS implementation, does there need to be a standard that would encourage multiple implementations? Probably not, and no standard should be created. Nothing is lost in the economy. People are collaborating on the implementation and not a specification for multiple people to implement differently. This tension can be seen in the lack of debate around the Perl language for a standard, but is interesting as people debate a Ruby language standard.
B. If the FOSS project acts as the reference model for a standard’s creation for which there will be multiple implementations, then is the FOSS project committed to maintaining the conformance to the standard specification once it is finished (e.g. OASIS and ODF out of the OpenOffice.org project). This would certainly aid the standard at promulgating faster if the FOSS licensing allows more people to adopt the FOSS project as a component of their products and services.
C. If the standard’s conformance criteria requires multiple genetically different implementations (e.g. the IETF), then one or more of them could certainly be FOSS licensed projects. This would again likely encourage the standard’s spread faster.
Standards and Business
Standardization does have an impact on business models. I’m an enormous fan of Christensen economic models. When a vendor begins to over deliver on functionality in products, and customers can no longer absorb the changes (or want to pay for them), the technology space is ripe for standardization. The standard can provide a reference model for a particular set of solutions to the problem and businesses (new and old) are in a position to offer new solutions to customers with the standard at their core. These new business offerings often have very different margins to the original vendor’s solution. New solutions with new margins create new business models.
IPR Tensions
The tension between standards and IPR is whether or not the IP licensing is [F]RAND or not. IPR and standards clash because they exist to support different functions within the marketplace. Standards exist to enable and encourage multiple implementations of the specification. IPR exist to protect a single idea’s expression or implementation. Every standards development organization (SDO) must deal with the reality of patents in the marketplace (regardless of whether SDO participants are the IPR holders). SDO create IPR policies to make the licensing situation as clear as possible for participants and potential future implementers. Ideally, no SDO wants to create standards with built-in taxes, but the reality is that there may be patent licensing to manage. Letting participants know the licensing landscape in the development process as early as possible is the goal.
The tension between FOSS and IPR is whether or not the IP licensing is [F]RAND and royalty-free. When FOSS projects implement standards, it’s no different to tackling any other endeavor with respect to patents, i.e. the FOSS project needs to be sensitive to the patent landscape. With respect to FOSS project participants, well-run projects fall back on a similar process to the SDO by creating some form of IPR policy. This policy is embedded in the project’s license choice/design, its contribution agreement process, or both. IP rights holders that participate in FOSS projects need to be as sensitive to how they manage those rights with respect to the FOSS project as if they were to participate in SDO, but the bar is higher because the expectation in a FOSS project’s IPR policy is that any patent licensing is royalty-free as well as [F]RAND.
A well-run FOSS project should take steps to ensure they have the same level of IPR policy considerations in place as SDO. As with the business world, the FOSS project needs any IPR to implement and distribute the standard implementation. FOSS projects suffer the same problem of patents outside their participants’ control.
Join the Forum discussion here: http://www.talkstandards.com/questions-for-standards-and-oss-open-forum/
