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

Reply via email to