Why all of the upgrades

[Bill MacAllister]

--On Wednesday, June 02, 2010 01:31:17 PM -0700 Joelle Crepsac <jcrepsac at stanford.edu> wrote:

> All,
>
> Thanks, for your comments; I think.
>
> I've suggested that 150 people (that do not have administrative
> privileges) use this application; an application that has had something
> close to 8 version changes in a few months.
>
> I don't consider that SO MANY revisions "active development"...
>
> I thought that I could actually get useful answer here; something that I
> could share with the 150 people I suggested this program to; something
> they could understand and relate to, and assist in creating some kind of
> trust and security in changing from their former instant messaging
> program.
>
> Unfortunately, the comments I've received so far aren't the type that
> should probably be shared.

It is clear that I misunderstood your original question, i.e. "Why is
this program constantly being upgraded?"  I had taken your question to
be an implied criticism of the quality of pidgin that it would require
that many fixes.  I am a happy user of pidgin and very grateful to the
developers who haven spent considerable effort working on pidgin and
allowing me to use it for free.  I felt that the least I could do was
to defend that effort.

It seems to me that you are really asking two questions, at least
there are two issues that I would like to respond to.  The first is
open source software in general and the second is system management.
Neither issue is specific to pidgin.

Open source software is not just free software.  While there are no
formal standards for open source development, there are some widely
accepted concepts that are generally part of open source projects.  I
think that Eric Raymond's introduction to "The Cathedral and the
Bazaar" succinctly describes the issue that is bothering you about open
source software.

  "Linux overturned much of what I thought I knew. I had been
  preaching the Unix gospel of small tools, rapid prototyping and
  evolutionary programming for years.  But I also believed there was a
  certain critical complexity above which a more centralized, a priori
  approach was required.  I believed that the most important software
  (operating systems and really large tools like the Emacs programming
  editor) needed to be built like cathedrals, carefully crafted by
  individual wizards or small bands of mages working in splendid
  isolation, with no beta to be released before its time.

  "Linus Torvalds's style of development—release early and often,
  delegate everything you can, be open to the point of
  promiscuity—came as a surprise.  No quiet, reverent
  cathedral-building here—rather, the Linux community seemed to
  resemble a great babbling bazaar of differing agendas and approaches
  (aptly symbolized by the Linux archive sites, who'd take submissions
  from anyone) out of which a coherent and stable system could
  seemingly emerge only by a succession of miracles."

Particularly relevant is "release early and often".  Certainly your
request for less often releases is at war with this general attitude.
There are many reasons that this makes sense and Eric Raymond
discusses several.  I would point out that cathedral upgrades can be
very painful just because so much tends to change when there is a long
time between releases.  Releasing often tends to mean that changes are
smaller and easier to install.

To be sure if this style of development is plugged directly into your
system management infrastructure there can be a lot of heartburn.  You
are not required to install the latest version of pidgin.  It makes
sense to read the changelog to see what has changed and whether it is
important to you before you apply it to systems that you manage.  Of
course, the ability be this selective implies that you maintain a
repository of software you install and have a method of deploying that
software to the systems that you manage.

For me the benefits of open source software out weigh the potential
problems and those problems can be mitigated by good system
management.  But, of course, that is my opinion.

Bill

-- 
Bill MacAllister, System Software Programmer
Infrastructure Delivery Group, Stanford University

>
>
>
> I withdraw my inquiry; please refrain from further attacks.
>
>
>
> Thanks anyway.
>
> Joelle
>
>
>
>
>
>
>
> From: Joelle Crepsac [mailto:jcrepsac at stanford.edu]
> Sent: Wednesday, June 02, 2010 12:47 PM
> To:
> Subject: Why all of the upgrades
>
>
>
> Why is this program constantly being upgraded?
> I truly regret sharing it because it's CONSTANTLY revision versions.
>
> Does anyone have any ideas when it will remain stable for 6 months or
> more?
>
> It's truly a hassle, and I'm considering using something more stable. Any
> ideas?
>
> Thanks,
>
> JC