Day Software’s chief marketing officer, Kevin Cochrane has recently been tweeting lyrical @kevinc2003 on Day’s business model as it applies to open source software.
In short, while the company’s web content management software is not open source, Day Software makes use of and contributes to a number of community open source projects, such as Apache Jackrabbit, Apache Sling, and Apache Felix. In fact, as the company notes: “in total, Day Software contributes to over 12 Apache projects and 25 open source projects. www.ohloh.org, an independent website that tracks open source contributions, shows that over 75% of Day engineers are active committers to open source projects.”
As Kevin explained in a series of tweets on August 10:
# alt model to commercial os: patron w/os core. at day we foster, contribute to liberal-use apache os but sell commercial product
# model gives best of both: os community dev not controlled by one single vendor (true community, all benefit) + trad software licensing
# w/liberal use, don’t need find GPL exception like a SaaS model – anyone leverage core OS components; even competitors can collaborate
On August 11 he followed up with:
# Day may not build a vendor-specific OS community …that’s because a multi-vendor community is much richer. Also why we like Apache license
# I think Apache Chemistry is good testimony to this. That project from time to time has heavy involvement from Day, from Nuxeo, others
# We all benefit. And because its shares perspective from a variety of vendor viewspoints is IMHO takes the OS better-quality arg farther
This strategy is not peculiar to Day. We have published reports noting similar strategies in use at IBM, SAP, and Oracle, for example (all those are only for 451 Group subscribers), while we have also noted that we expect the next phase of open source development to be characterised by the vendor-dominated open source communities that enable such a strategy.
I also previously mentioned that, if the trick to monetising open source is to maximise the benefits while reducing the risks, then in my opinion the strategy being used by Day and others does this better than the Open-Core approach:
“One of the reasons for this is that it sees vendors engaging with existing development communities (such as Apache and Postgres) or starting vendor-based communities (such as Eclipse and Symbian) which enables them to benefit from lower development costs, shared resources, many eyeballs etc for non-differentiating features while focusing their attention on value-add features and functionality. This can be done in a vendor-owned open source project, but it is much easier to be part of an existing community.”
What we have lacked with regards to this strategy is an adequate vocabulary to describe it. In our Open Source is Not a Business Model report we referred to the licensing strategy as “Open-and-Closed”, which did the job in the short-term but is troublesome due to its use of two generic words.
Similarly, we used Embedded Hardware and Embedded Software to refer to two of the revenue triggers used to generate revenue from this open source strategy, which are also problematic due to their use of generic industry terms (leading me to toy with the alternative Open Inside). Carlo Daffara, meanwhile, has used “R&D cost sharing” to describe vendor models that make use of Eclipse, for example.
With that in mind, Kevin’s use of the term “patron” to describe the model is certainly descriptive of the relationship between the vendor and the project. Ultimately though, definitions are a matter we will have to consider next year as we update Open Source is Not a Business Model. For now, we expect to observe the growing adoption and maturation of the strategy, whatever you choose to call it.