RE: Binary release announcements?

[address@hidden]

On Wed, 18 Feb 2004, Jim.Hyslop wrote:

> 
> A perfect case in point is the recent thread about the Windows build being
> broken - again. I've been through this many times with various open source
> projects, and trying to get the software to build just is not worth the
> hassle involved if there's a pre-built binary available from a site I trust
> (there's that word again).
> 
> Even when I can build from source, I always have a nagging doubt - what if
> I've missed some critical configuration option that hasn't been documented,
> or is documented in a very obscure place? I don't want to have to read
> through dozens of pages of documentation. I don't want to have to be
> intimately familiar with each and every build process for each open-source
> project I use. In many cases, I don't even care about the build step - all I
> want is the final product. With a pre-built binary, I don't have to
> second-guess myself. 
> 
> Again, you need to look at this from the point of view of the people *using*
> the software. You have to stop thinking like the hard-core UNIX programmer
> you are, and think like your users.
> 
> > As I understand it the
> > folks producing the source release don't also produce all of the
> > binaries, and I'm not sure how much they trust those who do 
> > produce the
> > binaries, nor if they've ever declared the level of their trust.
> As you well know, trust is a very personal thing. You, for example, appear
> to trust no-one or nothing on the 'Net. I respect that view, but it is not
> the same as mine. While I believe some caution and skepticism are healthy, I
> can see the desire and need to have some reasonably trusted sources for the
> binaries.
> 
> I trust that the maintainers of the cvshome web site will not knowingly do
> anything malicious, and will act quickly to remove anything from the web
> site that they learn is malicious.


The solution to this "dilemma" is obvious.  Provide both a pre-built binary 
distribution of CVS, and the sources in their current buildable form.  Then
it is up to the user to decide which distribution format they want to use.
Some organizations forbid the use of pre-built open source projects, so
they must build from source.  Some people don't have the resources to
build for Windows, so they will use the pre-built distribution. As for
trust, it will then be up to the user to decide what is their trust level,
and choose the distribution that fits their needs and meets their level
of trust.

When discussing building software, one way I judge complexity is by how many
dependencies the project in question has on other projects.  Take OpenSSH
for example.  You must build OpenSSL, and the MIT Kerberos library when you
want to use GSSAPI authentication, then you can finally build OpenSSH.  And
prior to OpenSSH 3.7, you had to apply a patch that provided GSSAPI
functionality.  Each of these projects are not lightweight builds, and all
of these builds have their quirks.  It is a real hassle to build, and it is
no wonder why many people choose to download the binary form of OpenSSH from
my work's website instead of building it themselves.  And trust is a serious
issue when talking about an SSH project.

CVS supports Kerberos and GSSAPI authentication.  I've never used those
features, but you will get into the same complex build dependency tree
with CVS as outlined above when those optional CVS features are used.

I find building CVS for Linux is a simple matter.  However, as with most
open source projects, the farther away from Linux you get when building a
project (for example Solaris, HP-UX, AIX, Tru64, Windows in that order) the
harder building the project becomes.  For some of these platforms and their
version, you must be a software engineer to get the build to work.
I can see how a binary distribution becomes an attractive alternative for 
some people.

The point is when people have a choice, they can choose what distribution
best fits their needs, and evaluate the trust issues for themselves.

Adam
---
Adam Bernstein   address@hidden   http://mpgedit.org/~number6
Key fingerprint =  E1 91 49 4C 24 18 E2 04  7A D3 78 A8 86 A9 7C 38