Proposal: Revision of policy surrounding 3rd party and non-free software

Stephen John Smoogen smooge at gmail.com
Wed Jan 22 18:46:46 UTC 2014


On 22 January 2014 09:59, Josh Boyer <jwboyer at fedoraproject.org> wrote:

> On Wed, Jan 22, 2014 at 11:41 AM, Matthew Miller
> <mattdm at fedoraproject.org> wrote:
> > On Wed, Jan 22, 2014 at 11:35:40AM -0500, Josh Boyer wrote:
> >> > From the Fedora perspective, there are users who have Fedora who also
> want
> >> > to use the Nvidia blob, and your proposal is to enable them. It makes
> sense,
> >> > in the sense that you are working to solve Fedora problems, where you
> have
> >> > some influence. "Fedora supports Nvidia" doesn't fly though, and
> regardless
> >> > of the language you use or implementation details like shipping
> metadata
> >> > instead of binaries, that *is* the perceived message of your proposal.
> >> A small but important clarification here.  In the proposal, Fedora
> >> would not ship binaries and would not ship metadata.  It would not
> >> ship anything related to a 3rd party repository other than knowing the
> >> web-accessible location of a repository.  It is, in effect anyway, the
> >> equivalent of doing a "google: nvidia linux repository" in a software
> >> installer.
> >> I'm not elaborating on the broader story, but I did want to clarify
> >> the technical details.  Fedora is not shipping anything in this
> >> proposal.
> >
> > Pedantic but (maybe) important distinction: the idea would be to
> prepopulate
> > (in some way or another) the software installer application with
> _specific_
> > 3rd party repositories (in the mockup, Adobe, Dropbox, Google, Nvidia,
> and
> > Steam) -- akin more to having the default Fedora bookmarks include the
> > download pages at those companies than to a Google search. Or am I
> > misunderstanding?
>
> The bookmark analogy seems fair to me, yes.  However, it might be
> feasible to include these "bookmarks" without having them displayed by
> default and instead requiring a user to toggle a checkbox or such to
> enable them.
>
> If you combine that with Bill's restaurant analogy from elsewhere in
> the thread, you could display your vegan menu in it's full glory for
> the user to peruse.  It could explain all the wonderful benefits of
> the items, and then have a footnote at the bottom akin to "not seeing
> what you'd like?  Turn the menu over for less healthy alternatives
> like shrimp and grits", etc.  Hopefully that analogy isn't too
> confusing.
>

Actually if I am running a vegan restaurant, I would just have a "I am
sorry, but we don't serve that here. There is a nice restaurant down the
street which does and I can call to make sure you have a reservation."

I would no more want Vegan restaurants to serve Shrimp and Grits than I
would want a Kosher restaurant to serve Bacon Lobster. Beginning to serve
either of those on the other side of the menu is making both restaurants
not what they want to be. Does it mean that the restaurant may go out of
business? Yes. But that is their choice and the market decided otherwise. I
realize that I am stretching a point here, but changing a restaurants menu
choices is one of the worst things to do to customers and you lose them
faster than you get new ones. If you are going to change the menu, you have
to change everything else (signage, menu, etc) to make sure the customer
knows they are getting something different. Otherwise you end up with
nothing but bad reviews, disappointed customers telling others to not come
back, and a spreading miasma that spreads to other restaurants 'owned' by
the same fellow.

[It works in restaurants and other industries where your patrons come from
loyalty and 'flavour' (health spas, barbers, baseball teams, etc.) I don't
know how applicable it is to Linux Distributions but I expect that due to
the small size and the intense loyalty it inspires there is probably a good
match.]


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20140122/9b36e0c9/attachment.html>


More information about the advisory-board mailing list