[csw-users] Resistance ?

[Brian Gupta]

I have tried to summarize the pros and cons, as I see them. In
addition I have added responses towhat I believe are perceived cons. I
am starting to make some progress, with my colleagues. I just now need
to come up with a workable stable deployment plan within the next few
months. For inclusion in our next refresh of our jumpstart build after
04/07. I am thinking we might need to keep a local replica of the
repository with point in time snapshots of older trees. But I digress,
I will start up another thread to discuss deployment methodologies.)

Here is an expanded list of pros/cons for your review and response.
(If you think it makes sense to incorporate some of all of this into
some knowledge base, feel free).

I believe the following are pros:

1) All Blastwave packages track dependencies and will install them
automatically (Unless you keep the default configuration to ask
first.)

2) Blastwave is completely independent, in that there are no
dependencies on libraries or packages that lie outside of the /opt/csw
tree.

3) Updates are released quarterly
http://lists.blastwave.org/pipermail/announce/2007-January/000042.html
(They rebuild and test the tree, once a quarter, to release the
quarterly stable builds)

4) Blastwave.org sends out email updates if a critical security bug is
found. They also immediately generate a new package and add it to the
stable tree. Sun does not provide this critical service for /opt/sfw
packages.

5) Saves time when installing finicky packages that weren't originally
built with Solaris in mind. (IE: Getting Linux only packages that rely
on Linux libraries to build, etc)

6) Dedicated team where each member is responsible for maintaining
certain packages, so they get very familiar with said packages.

7) 1500+ prebuilt packages in the repository.

8) Currently only one person in our group has the knowledge to  build
and maintain System V packages. If we went to /opt/csw this would no
longer be an issue.

9) Built with the latest Sun compiler, unless the package needs gcc.

10) Very simple to list all the packages, list installed packages,
update installed packages, and remove packages.

11) Packages are much more recent than /opt/sfw/

12) Blastwave has been releasing packages since Solaris 8. (Over 5 years)

13) The Sun /opt/sfw distribution is a VERY limited in the number of packages.

14) In the rare event that we need to compile our own package, if it
is built in such a way that it conforms to the Blastwave.org's
standards, we will have no conflicts, and could even contribute our
work to a larger community.
15) Do not have to maintain packages for multiple architectures, as
pkg-get figures this out and gets the applicable packages.


Cons:

1) Loss of control, I.E. - dependant on other peoples work.
    Response: I don't really fell that this is a big deal, as this is
the nature of all open-source software.

2) What if a package isn't in CSW.
    Response: This is rare, but in the case it is, we are no worse of
than before, and would just build a package that complies with
Blastwave's standards.

3) Takes up a lot of space.
    Response:  I feel that we can spare a few hundred megabytes (or
even a gig or two), considering the huge size of modern disk drives.

4) No leverage over Blastwave.org, as we do over Sun.
    Response:  Our most critical packages aren't even in /opt/sfw.
They are hand compiled by us. At least with /opt/csw, you have
dedicated maintainers, and a community, that you can go to for
support. If you are still concerned, we can always do the same unit
testing we do with our own hand built packages. In addition, because
Blastwave is community supported, Blastwave's continued success
depends on making sure they have a good reputation with that
community. Because their process is very transparent, we know what
they are doing, and why. On the other hand you have Sun's unsupported
packages. We have no visibility into their build process, nor do we
have any quick course of action to get these packages fixed. We don't
even know who is maintaining them, or for that matter, if anyone is
maintaining them!

5) To much change to our environment.
    Response:  Rolling out /opt/csw in itself won't change the
environment. (For that to happen you need to change LD_LIB...PATH, and
PATH in .profile. We can also rollout one package at a time, as we
need to upgrade them, and change the /usr/local symlinks as we roll
out the individual packages. (This way we would not become overwhelmed
with testing. Once this is in progress, we can choose to completely
get rid of /opt/csw when we make our next build.

6) How do you make sure that if I roll out Samba today, and then roll
Samba out to another system six months from now, I won't have
different versions.
   Response: My take on this is the preferred method would be to
upgrade all the old versions of Samba, which would bring consistency
across our environment. The one problem with this line of argument is
that for most organizations they rarely update their production
version of there sidecar of open source tools. (Short of security
alerts) There is a healthy fear of change.

7) Blastwave.org could fold. When it comes to open source packages, it
doesn't matter if the maintainer goes away we can always go back to
the source, and use the packaging standards and methodology that
blastwave initialized.. (I'm afraid of this option, but it is an
option) I think that in many organizations keeping a mirror of both
the build tree and packages repositories will help provide assurance
in the event of the blastwave organization running out of funding, or
interested parties.

I was wondering if blastwave has documented any automated unit testing
that is done on the binaries? It would be great if I can show to
people that before every stable build that blastwave as actually
running the binaries with every option to a) make sure any syntax
didn't break, and b) that the binaries actually do what they are
supposed to. (Or at least will do what they did in prior versions).

One last closing thought, is there any chance someone has any pull
with Sun and can find out if they could join efforts with you? (I am
referring to their resource starved /opt/sfw package tree) If Sun is
going to supply community software that won't be supported, and is not
really kept up to date, I feel it would make more sense for Sun to
throw their "unofficial" support behind the community project, and
reasign those engineers that are working on /opt/sfw to work with
blastwave.org.

One last, and really final, closing thought to Dennis, and friends. I
sense that there may be a business opportunity here or in the near
future. An official source of support for users of blastwave, could
potentially have a very large customer base, if you take the amount of
traffic your site gets.  (We corporate types are so used to having a
neck to choke, it is unnatural to us to walk without a guide)

Thanks,
Brian

On 4/11/07, Dennis Clarke <dclarke at blastwave.org> wrote:
>
> > Dennis Clarke <blastwave at gmail.com> wrote:
> >
> >> The one argument that you will get thrown at you is that you can not
> >> trust the logn term existence of a community project.
> >
> > You might hear that, yes - but can you trust the long term existence
> > of a company or a commercial product? Can you? How? What makes you think
> > that? Is it not thinkable, that a "hostile" company buys another company
> > and then stops the production of a certain program?
>
>   Well, if I apply that line of thinking along with the multiple interjected
> little question marks then the answer is no. You cannot trust anything.
> The sun will burn out in a few billion years. Long before that we can
> expect another ice age. Possibly bad weather. Also, I will be dead. So
> will everyone that you know and all these corporations will be less than a
> historical footnote.
>
>   So .. over and period of time you can depend on nothing and no one.
>
>   There .. having said that you really have a hard time debating the
> existence of this community project as well as the software released. It
> exists today, yesterday and probably for quite some time now. So if you
> want to hand roll your own because you can not depend on any given vendor
> then thats fine. Just know that you may be totally right and wrong at the
> same time.
>
> > IMO the argument that you, Dennis, brought up is totally flawed. Especially
> > if we're talking about (now) large projects as Blastwave, OpenSolaris,
> > Debian, ...
> >
> > (Yes, I know that you, Dennis, did not mean it that way.)
>
>   I think I was trying to simply say that we are here.  For any given short
> sample of time you will see the project exists. If that sample window gets
> too large then you will see that nothing exists.  I think that maybe the
> limit of the average mass of the universe as time approaches infinity will
> be zero.
>
>   nothing exists ?
>
>   how ever will I send this email ?   :-)
>
> Dennis
> _______________________________________________
> users mailing list
> users at lists.blastwave.org
> https://lists.blastwave.org/mailman/listinfo/users
>