Definition of a Community-derived Project
Friday Jun 01, 2007
Per my last post, I'd like to describe what I mean when I say non-Sun-derived (i.e. Community-derived) project.
But first, make no mistake. I believe -- as everyone does -- that
it's perfectly fine for many/most OpenSolaris projects to
be totally Sun-derived, Sun-designed. But not this one -- not the project that wants to lay claim to the title OpenSolaris reference distro!
OK, here's my definition of a non-Sun derived OpenSolaris project:
The design goals (both initial and ongoing) of the project are derived a.) independent of the desires of all levels of Sun management, and b.) independent of Sun's Business goals, leading to a broadly held perception (by reasonable, open-source savvy people) that the project's course is fundumentally not Sun-management-controlled.
Regarding origin and impact of project resources: if Sun pays for resources for a non-Sun derived OpenSolaris project (per my definition above), that influences things like program management, speed and quality of project execution, marketing, etc. (IOW, definitely not the project's power to ultimately self-arbitrate.)
So that raises this question: What's the Wallstreet business case in that? Why would the board and other shareholders want Sun executives to direct lots of money in this way?
- In the software world, volume wins.
- Success of an open-source software project builds volume, and does so in a way that no other software strategy can match (not even close).
To my knowledge (for what it's worth), the two bullet items above are core tenets of SUNW's software business plan. Therefore, because an excellent OpenSolaris project with excellent core contributors is excellent for OpenSolaris, Sun should invest tons of resources in both kinds of projects (Sun-derived and Community-derived), even though Sun cannot ultimately control many of them.
|
|
|
|
