[ogb-discuss] Device Driver Community

[Alan DuBoff]

On Fri, 4 May 2007, Roy T. Fielding wrote:

>> To be honest, it doesn't say much at all. What is the point in having Core 
>> Contributers and/or Contributers might I ask? Other than voting rights, it 
>> doesn't seem there's much meat to it.
>
> One of the most important things for open source projects is to properly
> acknowledge contributions.  In many ways, it is the only thanks that
> anyone gets for contributing toward the goals of the group.  It is also
> essential for tracking intellectual property claims when they occur
> (and they *will* occur, even for a nonprofit like Apache).  The
> Contributor category and associated requirements exist to document
> the responsibility of Groups for maintaining a list of credits.

That's a valid point, most certainly. But wouldn't the license be the 
determining factor on IP?

> The Core Contributor category is to identify the people who are able
> to make decision for the Group and to emphasize that we want the
> people doing the most work (or having invested the most time) to be
> the ones responsible for making decisions, rather than just whoever
> writes to the mailing list today.

And that's important to some.

> Note that there are a lot more ways to contribute than simply coding.
> It is difficult to list them all, so we left it wide open.

Sure, but I was thinking there would be some type of guideline so that 
things were more consistent across a community at large, for user groups 
for instance. The way in which it was decided didn't account for any type 
of consistent action, and the results display that.

>> I would encourage the OGB to draft up some type of guidelines and/or change 
>> the name of "leaders" to "editors" possibly, it's confusing.
>
> I agree.

This seems to be in agreement that something should change in regards to 
this, so I'll let the OGB work that out.

> As an "outsider", my perspective was that the notion of consolidation
> and the products grouped into consolidations were both completely
> arbitrary accidents of business reorganizations within Sun.

I am not sure I understand why, but even in other distributions such as 
Debian, they have several areas that could be considered similar. free, 
non-free, contributed, ...

I'm not sure why a consolidation for ON doesn't make sense, it seems that 
many distributions would want/need to use it and include it in their 
distribution. It is a consolidation of software. The same applies to free, 
non-free, contrib, for Debian in many ways.

> Even
> after all this time, the current consolidation structure makes no sense
> to me.  That is why they aren't in the constitution.  I figured it
> would be better to leave it unspecified than to write something into
> the constitution for which I did not understand the rationale, let alone
> the desired structure for opensolaris.

Because they didn't make sense for you, is quite honestly no reason that 
it doesn't make sense to others. That is after all why we have 7 member of 
the OGB, so that no one point of view could be taken by any single board 
member, no?

> AFAICT, consolidation just means a release management process for a
> given set of products.  In my opinion, that should be a project of the
> community that owns that product(s).  However, I am sure that you guys
> have a much better handle on how consolidations coordinate work in
> practice (at least from the perspective of Solaris releases), so you
> are in a much better position to define it correctly than the CAB.

No, I think this is true as I see it also, just that you view the entire 
distribution (for lack of a better term) to be one large consolidation, 
which it is.

The problem with a large consolidation is that there are overlaps and grey 
areas between them, so grouping them together in smaller consolidation not 
only makes it easier, but allows for a way to deal with those 
consolidation as a group, rather than a whole.

> If OpenSolaris were producing a distribution, then I'd suggest a
> single consolidation structure along the lines of Ubuntu Linux.
> In other words, a distribution community that is responsible for
> overlapping "release" projects that terminate every six months.
> Then the individual product releases (managed by each product's
> community) would be independent from the overall release project.
> But, YMMV.

It is one way to look at it, but creates a very large consolidation to 
deal with as a whole. If consolidations were smaller, it would allow more 
people to use them. As an example, if we did have an embedded community, 
it could include the needed components of an embedded system, so that 
people building embedded distributions could get them as a whole. By 
lumping those all together might make it more difficult for embedded to 
strip out what they want.

In the same light, would an opensolaris distribution targeted for destkop 
really need software such as busybox? I think probably not, but many do 
have it (Debian, Red Hat, etc..). For most all purpose, there is no reason 
to duplicate the standard system utilities with something such as busybox 
if you have the space.

--

Alan DuBoff - Solaris x86 IHV/OEM Group