Am 23 Apr 2010 um 04:04 schrieb Richard L. Hamilton:
Surely "sufficient people" exist that would pay for low-end support
(sunsolve+patches only, or sunsolve+access to a repo with bug fixes,
for OpenSolaris)
that otherwise might simply do without, or go elsewhere.
Staying profitable is important. But just because big customers can
afford
to drop big bucks, doesn't mean that small customers (home users, home
businesses, students, etc) might not also be willing to spend what
they reasonably
can for a relatively modest (little direct consumption of man-hours)
level of support.
I just don't see the profit in not taking the little guys' money
too; surely it adds up...
Agreed, but there's a much larger point to be made about customer
segments that may not be targeted by Oracle, which is that they can
add real value under the right community model, which may be of value
other than opportunities to realise substantial revenue. I think there
are at least three areas where OpenSolaris can expand or supplement
Oracle's business model:
1) grid computing, where hardware is priced strictly for volume and
the RAS profile is at the grid rather than system level and there's an
advantage to aggressive tracking of system-level software updates that
respond to your computing profile; Oracle may not be able to play for
the hardware price point for this business, but rather than
surrendering this space to Linux from the get-go, work with customers
who want aggressively commodified hardware from another vendor but
will sign on as OS-only support customer or and even sponsor
improvements in the dev branch of your systems and/or development
stack; the point is that there are places where picking up customers
can grow the technology, but tying the customer base to hardware sales
may otherwise cut off this possibility, making it interesting to have
a support and development offering for OpenSolaris, where Oracle would
allow third parties involved in the community to set up contracts with
Oracle for support and then re-sell support to customers, providing
some combination of derived builds or experimental branching that
doesn't guarantee put-back to the Oracle repos;
2) recognising that there is also a volume business in selling low-
touch OpenSolaris subscriptions to the community to give you both a
modest revenue stream and a feedback loop for bug reporting; ideally
there would be some recognition of community contributions to
OpenSolaris in the form of subscription fee waivers, such that people
can choose between paying or development involvement, where the latter
also has direct economic value to Oracle–there has to be some
corrective to avoid make-work projects gaming this system (submit a
bunch of enhancement requests to fulfil them yourself and then bank
the resulting credits, where there is little to no agreement that
these really are enhancements: there has to be some notion of exchange
value here, which necessarily requires recognition of value by
others), where this may require some expansion of the community
governance model; the idea isn't that OpenSolaris would be available
only by paid subscription but that that consumer participation
3) selling combined development or integration bundle subscriptions
for the OpenSolaris, allowing a similar in-kind recognition package,
extending a modified community model to the value-added products; the
premise would be something like this: the core code for something like
clustering or compilers wouldn't be open, but APIs and extension code
would be open under a community model; thus, if I wanted to provide
cluster support, I could get such a subscription that included
clustering; I wouldn't be able to deploy the clustering product
commercially myself, but I would be able to write and test the
integration code and make it available to others from a common,
community-licensed repository, resulting in a core product that isn't
open for development but for integration, where the success of the
integration product substantially contributes to the use value of the
product; there are some issues here that would need to be resolved to
clarify support liabilities and determine revenue recognition, which
appear necessary parts of the redistribution which creates value;
(A possible fourth area is pushing open standards back to the centre
of the portability story, where FSF/GNU/Linux has become something of
a de facto standard with some resulting distortions and real risks of
monoculture. There are inherent advantages in having large amounts of
source-distributed software that's portable to OpenSolaris, Solaris,
and other standards-compliant *nix distributions, and it is therefore
important to minimise costs of entry and access for anyone writing
software that is freely available across compliant platforms. Not that
I love the standards process, but I don't think that Linux has such a
monopoly or strong relative advantage in quality that it's healthy to
let things slide their way because they are the de facto primary
development platform for *nix.)
My preference for community recognition in subscriptions would be to
provide something like sweat equity shares that could be exercised in
more than one way: not only could you cash in your shares for
community software entitlements, but a portion of OGB votes would be
allocated on a share basis. Perhaps there might also be a community
project sponsorship system, where people could allocate shares as
votes for favoured projects that would be liquidated in a successful
bid. This would let people who were successfully contributing
expertise in one area support development in other areas where their
expertise wasn't readily applicable but which they understood to be
important work. Oracle would retain over put-back to the official
repos and have mechanisms like ARC cases to control architectural
direction, but the community could play an important roll in providing
additional developer resources and possibly threading the needle for
enhancement requests, such that the community could filter out and
refine requests that would require Oracle feedback and approval. Those
wanting to act as contractors could pursue parts of the market that
didn't fit Oracle's business model without having to go so far as to
fork or branch too far out, although this would remain an option. A
contractor could reduce direct costs for licensing and support and
extend OpenSolaris expertise at the same time by contributing
substantially to community-sponsored projects (like providing open-
source replacements for components distributed as binaries). They
would also have the option of reducing direct costs by supporting
integration of OpenSolaris-related technologies. The point here is to
reduce capital and contract costs associated with open development
around OpenSolaris and focus on realising productivity value for non-
Oracle resources.
My view is that, rather than spending time batting down rumours
implausible on their face (certainly when read attentively and backed
by modest amounts of research), there should be broad discussion in
the community about strategic ways forward for the relationship
between Oracle and the community. (As for rumours, I think the
standard needs to be that people posting rumours that can be disproved
with fifteen minutes of Googling or that are presented without at
least linking in contradictory indications that can be found by the
same standard, should be bounced from opensolaris.org lists, with just
one warning for misbehaviour.)
Cheers,
Bayard
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org