[ 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.
From what I can see BIND development has slowly become less public over
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? 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. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>