Thoughts from last meeting

[inode0]

On Sat, May 26, 2012 at 8:46 AM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> inode0 <inode0 at gmail.com> wrote:
>> But at the same time inclusion of *any* package at all in EPEL can
>> cause problems for GSS.
>
> As I sorta hinted earlier, I do have to admit that it goes beyond just
> things in Fedora like EPEL.  There will always be the reality of
> people who will try to utilize Red Hat's support for not merely what
> is called "unpaid" open source, but open source that Red Hat has not
> unit, integration and regression tested as a whole  As much as it may
> bother some when people take advantage of Red Hat individuals and
> their goodwill to "share" in paid, subsidized aspects, there can be
> grave contractual issues when it's in an enterprise.
>
> Most of the time, it's overlooked.  But when it's on behalf of paid,
> but proprietary IHV/ISV who is shipping, referring to or otherwise
> providing an "unpaid" open source they don't even support, I really
> hate to have to remind people that it's unfair to do that to Red Hat
> (let alone "throw them under the bus" when I see it).  The better
> response would be for a customer to go back to the costly, proprietary
> IHV/ISV and ask them why some of their money is not funding Red Hat
> entitlements instead of ripping the "unpaid" open source from the
> community.
>
> So while I'm sure anything that can be done to avoid "accidental"
> support is appreciated, no guidelines can prevent intentional misuse
> of Red Hat's trust.  To me, it's not much just users who are "caught
> in a bind," which happens, and I've never seen anyone in Red Hat just
> say "no" to such users.  But far worse from my view, it's proprietary
> vendors who do it very, very intentionally, and leverage the users and
> the community to "walk through the open door" they already have with
> Red Hat, instead of doing it themselves and walking in with the
> customer.

None of this is a problem that EPEL can solve. We accept packages that
meet various criteria that are more restrictive than other 3rd party
repositories. If an EPEL consumer, whether a Red Hat customer or not,
wants something in an upstream repo and EPEL won't provide it for
whatever reason there are others that will provide it. So Red Hat will
have whatever support problems result from customers using the package
either way.

>> For large, well-heeled, enterprises it doesn't matter what content
>> EPEL includes because those enterprises take full responsibility for
>> what content they allow into their enterprises. I doubt most EPEL
>> consumers actually function this way though, even though they might
>> very much like to.
>
> Actually, most do.  EPEL gets special consideration as a Fedora
> Project, understood to be unsupported, but a better release avenue
> than "rolling your own."  The key is for stakeholders and SMEs to put
> this in the proper context for other, both technical and
> non-technical, stakeholders.  It's hardly alone in the software world,
> as even proprietary, commercial vendors have their unsupported tools
> and utilities, along with other communities.

Are you seriously saying that most EPEL consumers behave in their IT
shops like large financial institutions? I'd bet not 1 in 10 do. I'd
probably bet not 1 in 100 do. EPEL is the 1st choice of many small IT
shops because they make the decision that they can trust EPEL to vet
packages for them. They want to get a package they need by enabling a
repo, installing it, and going back to figuring out why backups are
failing. :)

John