On Wed, 9 Jul 2008 10:53:35 -0400 "Fredrich Maney" <[EMAIL PROTECTED]> wrote:
> > ON is in the early stages of this now, with three or four software
> > repositories maintained by multiple groups (and at least one
> > distribution that's apparently trying to include everything modern
> > Linux distros include). Since they each use a different base
> > directory, they can coexist, so it's not as bad as Linux was or
> > is. However, if I want something that's not in either of them, but has
> > requirements some of which are in one and some in another, I'm pretty
> > much wedged (the one time it's happened so far it wasn't as bad as it
> > typically is on Linux, though).
> That is a problem for the application provider to resolve, not the OS
> vendor. If a 3rd party developer wants to port their application to a
> given OS, then they need to do the legwork of making it work within an
> existing vendor or 3rd party provided repository, or they need to
> provide all the dependencies themself. If you are wanting to port
> application to OS then the onus of doing that legwork falls on you.
> That has always been the case and I don't see a problem with that
> paradigm.
True, and I'm not advocating changing that - though in practice, the
a lot of the people contributing to the OS will also be contributing
ports to that repository.
> > By having a repository of such software that is a "vendor blessed
> > build" - even though the vendor may do nothing more than make sure it
> > builds properly before checking it in and making it available - you
> > provide a common base for people building FOSS software to work from.
> > So if I want to build a package that needs foo, bar and baz each of
> > which depend on one or both of gort and glub, if I find foo, bar and
> > baz in the "vendor blessed build", I know they will all use the gort
> > and glub from the same repository, and hence work together. There's
> > some other properties I think such a repository needs to be really
> > sucessful, but it's existence has to be the first step.
> I think it has been proven time and again that it doesn't make much
> sense for any vendor to be in the business of providing 3rd party
> applications - they end up catching the blame for the problems with
> that application and being forced to develop/support in order to
> minimize that user frustration. That is one of the main reasons we end
> up with code forks in FOSS.
It may have been proven time and time again, but there are also
examples where the vendors get into that role, and manage to do it
without undo problems. Yes, they sometimes get the blame for broken
third party software - you'll never avoid that. You'll get blamed by
software authors who write for some platform where XXXX works in spite
of being flagged in the posix docs as unsafe and then it doesn't work
on your platform. Nothing can prevent that. The vendor needs to learn
to be able to tell the difference between things that really are their
problem and things that really aren't, and when to say "no" (or when
to say "if you want us to fix a problem that's not ours, you'll have
to pay for it" :-).
I, on the other hand, have never seen a case where there wasn't a
vendor-blessed repository of third party applications for a platform
that didn't wind up with multiple incompatible repositories and users
who are regularly frustrated by either loading multiple version of the
same software or having different software need incompatible versions
of the same dependency whenever they need software not provided by the
vendor. ON is not an exception to this, and that's the primary reason
that - in spite of all the really cool things Solaris has to offer -
my development boxes aren't running Solaris.
> A better solution for Sun is to support a 3rd party organization (like
> Sunfreeware, Blastwave or OpenSolaris) taking on that role. They can
> provide support, funding and expertise to that/those organization(s)
> in exchange for some degree of control/guidance to insure that
> everything plays well together and follows the same general direction.
That may be the case, given that Sun is a commercial organization
rather than a non-profit. However, to best leverage the skills in
those organizations - as well as minimize user frustration - Sun
should pick *one* such organization and encourage the others to
contribute to that one; should list the one they pick as *the* source
for third party applications; should encourage people who port
applications to submit them to that organization; and should encourage
anyone building distributions to use ports from that repository and to
make it a default source for adding packages. They should also give
the people who can commit to that repository access to the ON bug
tracking software and a category, so that users don't wind up having
to resubmit misfiled bug reports, but developers can just change the
category.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
