[ On Sunday, February 4, 2001 at 10:10:55 (-0800), Roeland Meyer wrote: ]
Subject: RE: Reasons why BIND isn't being upgraded
So do I, <yea, Paul!>. Managing an OpenSource project, with volunteer
programmers, that can take off to smell different roses, anytime, is a royal
PITA! It's much worse when you can't pay for it. The OpenSource model makes
ALL of its money from service and support, while giving the code away for
free. This is almost the exact opposite of the traditional model. If you
want support, you should pay for it. If, that is, you want BIND to continue
to exist.
Fine. However you cannot pay for support under an NDA, to the project
leaders/owners, without causing grave issues for the rest of the open
source community, especially those of us who are paying for their use of
that project through their own volunteer input to either that project or
some other complimentary project(s) [eg. an OS on which the first runs].
It would be perfectly fine for anyone not directly linked to the project
leadership and ownership, like myself for example, to provide services
under NDA for BIND. However to have anyone directly associated with
ISC, Vixie, Nominum, etc. do so is damaging to the open source community
regardless of what their true motives are.
On the other hand if the true official source repository for BIND were
put out in the open, preferrably on some independent third party server,
then there'd be a clear way to make ISC accountable. They (i.e. ISC,
Nominum, etc.) would still be able to create their own private releases
for their contract customers, just as anyone can, but the official
public releases would be cut only from the official, public, repository
and any differences would be immediately, and publicly, visible. No new
fixes should go into the public release without public review and public
accountability -- that is, after all, what open source is really all
about! (And that way the contract customers would truly get their
money's worth too! 
Open source projects defintely need leadership, engineering, and
management. Whether those things are done by an individual or group and
whether they are contributed voluntarily or paid for directly by a
narrow segment of the community is not really relevant. However open
source projects cannot "do good" for the community as a whole if bug
notification, fixes, QA, etc. are all done under NDA to a select few and
with invisible and unaccountable delays. If the majority of the open
source community is only able to follow in the footsteps of of those
select few then they will be no better off than those who choose
proprietary solutions. Public accountability is removed, or at least
greatly reduced, the more the select few hold the project accountable
only under NDA. This is why the open source community as a whole scoffs
at the offerings of Sun, etc. Until/unless their development really
happens in the open their offerings will be mere curiosities. Should/is
BIND development going the same way as Solaris?
From what I can see BIND development has slowly become less public over
the years under Paul Vixie's leadership. These days those of us on the
public bind-announce and/or bind-workers lists only hear about where we
can download new alpha, beta, and release-candidate code up until the
time that a security vulnerability is discovered. Then all goes
silent-running until suddenly there's a new official release (be it a
patch release or a full release as 8.2.3 was). In the old days
(i.e. well before the 9.x project started) it seemed to be that there
was never a release unless at least bind-workers had been given a
release candidate to test and the differences between that test release
and the official release were always minor. These days we just never
know what's going on until after it's all done and then we scramble like
everyone else to get caught up.
If you want support, you should pay for it. In fact, even if you don't need
support, you should pay for it anyway!
This isn't really about the issue of who pays who, but rather who's
bound by an NDA to whom!
I pay for my open source "support" by contributing directly back to
projects with fixes, free support, documentation, new features, etc., as
well as with services in kind on other open-source projects. Should I
be under NDA too? For which projects? What hogwash!
If I were, for example, to begin providing secret support for any open
source product that I currently "officially" lead, and then refuse to
give fixes to those who discover that I'm doing this, my project is
either going to be "forked", or abandonded for some equivalent
alternative (with the choice usually dependent on the type of copyright
license). The very same thing happens if other public volunteers find
their contributions are being totally ignored. Open source projects can
only thrive under their existing leadership if the public community can
hold that leadership accountable and trust them to manage the project in
such a way that fixes (and features) are turned around and made
available to the community in a timely fashion). I am "painfully" aware
of these facts. I have been, and am, firmly on both sides of that
fence!
So, I guess what I'm saying is that I have no real problem with what ISC
is proposing to do with BIND. All I'm saying is that regardless of what
they end up doing in the end, the open source community will change and
adapt to suit. What that means is anyone's guess at this point....
My only real suggestion is that ISC take a much closer look at the real
process in the various truly open and large development projects, such
as the *BSDs, and various significant projects managed at SourceForge,
especially those managed under similar copyright licenses. Their succes
seems to depend on having a larger and diverse developer community with
direct commit privileges. Their usually strict release management
processes ensures that fixes are available in a timely fashion and are
performed in a very publicly visible fashion. They usually have a
security officer or team responsible for producing and approving source
patches, etc. Sure there are often people producing proprietary
releases, and often those people have commit access to the public
repository too, but the public development and release process remains
relatively un-affected by their involvement.