Date: Mon, 12 Mar 2001 15:05:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: scanner@jurai.net Cc: freebsd-chat@FreeBSD.ORG Subject: Re: BSDi's replies to why BSDi sucks... Message-ID: <200103121505.IAA16021@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.21.0103120558210.18282-100000@sasami.jurai.net> from "scanner@jurai.net" at Mar 12, 2001 06:34:44 AM
next in thread | previous in thread | raw e-mail | index | archive | help
From the context and your report of his comments, I have to say that Bill doesn't "get it". It seems that, in demanding a "manager", he's trying to apply the tool he knows to a situation where the tool isn't needed. Apparently, he wants a leverage point that will grant control to the wielder. That's a very strange thing for him to want, from a FreBSD perspective, but a natural one to want, from a business perspective. The problem is that he wants to control a volunteer effort in order to build what he thinks should be built, instead of what they will build out of interest. This is the same mistake Mozilla made, and the same mistake Sun has made with Java (and then componeded it with a license which makes it practically useless; the only thing it has going for it is the old MIS manager's dream of being able to get rid of all the tiresome programmers -- a dream which will never bear fruit -- so that these days, if you can spell "Java", you can get a realtively high paying position). The statement "There is alot of friction between the BSD/OS side and the OSD people. Mainly because of stupid things the OSD wont accept and that should never have happened." is very telling. If there were a "manager" (what he really seems to want is a person who is to FreeBSD what Linus is to Linux), there would be someone that they could pressure to get FreeBSD to do what they want, such as accepting changes from BSDI "for their own good". I think that it's generally understood that the only person who could credibly take on this role would be Kirk McKusick. I think he also misses the point, and protrays one of the greatest strengths of FreeBSD's as a weakness: people work on what they feel needs to be worked on, and "owning" several core team members and/or committers doesn't give you carte blanche write access to the tree. They need to learn from other commercial organizations which have used FreeBSD in their own products -- they need to learn from Walnut Creek CDROM, however much of that is left. Sure, FreeBSD has poor productization, and while easy, the install doesn't have that polished look of Windows (I think that maybe BSDI had hoped that FreeBSD would become Windows 2000 desktop to BSDI's Windows 2000 server). The FreeBSD organization also has limits to the complexity it can handle. Big projects don't get done without a lot of buy-in from the group, and complex projects can't be done by large groups of hobbiests -- most of the complex things which have happened in FreeBSD have had commercial funding of a small team actually doing the work. There's truth to the old addage that begin "too many cooks...". Another interesting thing is that complexity is exactly where large companies are attacking their Open Source competition. There are many new standards that have been pushed through the IETF at significantly high complexity levels, compared to what went before them. Much of that complexity is, IMO, gratuitous and aimed squarely at being too difficult for an Open Source project to implement correctly. Microsoft and Novell are old hands at this game, with their obscure wire protocols for file sharing: Microsoft intentionally, and Novell by way of including all of their historical APIs in their client developement kits. Novell has actually been hoist on its own petard by doing this, since programmers will use the oldest APIs they can to get the job done, since they want to capture the largest potential customer share from the installed Novell base. In turn, Novell servers have to support all the historical APIs to keep such programs running against new servers. Netscape actually tried its hand at the complexity game, to try and control the LDAP market. I actually gave very bad odds of the OpenLDAP project ever implementing LDAPv3 because of this, given their initial license, and given what I knew about the FreeBSD and Linux capabilities in this area. I warned Kurt Zelinga about this when he started, and actually distanced myself from the project because of this. Happily, I've been surprised, and Kurt's style is closer to the Apache/XFree model, which doesn't have the drawing power of the FreeBSD model, but which likewise attracts only highly skilled and self-disciplined people. Put simply, FreeBSD and Linux have a lot of activity, and OpenLDAP and Apache have a lot of action. Realize also, that a single commercial employee working with the project as part of their work can have much more impact, and therefore control, than with FreeBSD or Linux (unless you buy Linus, as Transmeta did, and even then, you don't get as much control as you thought you were buying). I think that's what BSDI thought they were getting when they bought Walnut Creek CDROM; maybe now they are having some "buyer's remorse" about not getting what they thought they were buying. That's really a silly and short-sighted view, I think. It ignores what they ended up getting, out of pique for not getting what they thought they were paying to obtain, and so they are squandering what value is there out of self pity for what isn't. Obviously, Bill's just one guy; his views may not be all that representative of the views of BSDI at large, and so this trieste might just be about Bill's understanding. On the other hand, if BSDI is really losing FreeBSD folks from their ranks, it's probably a view which is more than just one person deep. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103121505.IAA16021>