I'll give you two scenarios of the kind of activity that CPF hopes to
engage in. The CPF did not spring to life in a vacuum, and both these
scenarios are representative of the sort of situation that led people
to think that there was a need for CPF.
(1) A software company has Product X that contains Component A, and
through A the product interoperates with another company's product Y.
As an alternative to Y, open source Project Z has also sprung up and
gained popularity. So the better Component A interoperates with Z, the
more of Product X the company will sell. So the company makes the
business decision that Component A should be released as open source.
They've decided this because it's a relatively self-contained piece of
software that can be open sourced while still enabling them to
productize X, and because they don't have the expertise in product Y
or project Z to dictate how interoperability should go. Better to put
this in the hands of the community where that expertise resides, with
the rights to make needed modifications. Devs from the software
company can continue to work on the now open source Project A to make
sure it still does what Product X needs it to do. Note that the Ayende-
type dev passionately working on Project Z benefits because he's now
interoperating with an open source project he can examine and fix
instead of black box that leaves him at the mercy of the software
company to recognize and fix issues.
Sounds great, right? So what's the catch? Well, here are some typical
problems that come up:
* Product manager: "So this is going to be out there with our name and
our brand on it, and other people will be modifying it in ways we
can't necessarily control, and using it in ways we can't determine? I
don't think so."
* Lawyer: "What about product liability? No one's going to sue the
open source devs on this if something goes wrong, because they aren't
a legal entity and they don't have any money. They're going to sue us.
I don't think so."
There are lots more objections of that kind. If you think those
objections sound silly or trivial, well, then that probably explains
why you're a dev and not a lawyer or marketing professional.
The solution? The software company contributes the code to Component A
to the CPF, and when their devs work on Component A they do so under
the auspices of the CPF rather than as employees of the company. The
company still has involvement in the project as required by Product X,
but none of the exposure that raises concerns. The company is still
working with a recognized legal entity, rather than an amorphous
community, and that legal entity is the target of any concerns rather
than the company or any project devs.
(2) A software company has Product X that interoperates with another
company's product Y. As an alternative to Y, open source Project Z has
also sprung up and gained popularity. So the better Product X
interoperates with Z, the more of Product X the company will sell.
Project Z contains Component A that handles the bulk of
interoperability, and so the company decides to include Component A in
their Product X. The company will even have devs work on Component A
to improve its interoperability with Product X.
Sounds great, right? What's the catch? Well, here are typical
problems:
* Product manager: "What if the project doesn't prioritize my
features? What if the development path for the project goes in a
different direction? And what are our customers going to think about
3rd party code of uncertain origin in our product?"
* Lawyer: "What if this code unwittingly infringes on somebody else's?
And how are we going to assume liability for 3rd party code in our
product?"
And of course lots more questions like these.
Solution: This is a harder case without a perfect solution. Open
source projects are going to go their own way. That just is the nature
of open source. And a community just is less concerned about liability
than a company, which is a legal entity with assets. At the end of the
day companies will include OSS in their products because competitive
opportunity outweighs business risk, not because there is no business
risk. But if a project is accepted into the CPF, and that acceptance
is with an understanding that the project is working in partnership
with certain software companies, then these concerns can be somewhat
addressed. The CPF serves as a mediating entity, both in a legal sense
and in facilitating coordinated project direction. For companies, this
mitigates risk. For projects, this expands the user base by letting
the project ride on the coattails of a commercial product. That ought
to be a win-win.