Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!hookup!newshost.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!agate!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: comp.unix.bsd.freebsd.misc Subject: ISPs and other commercial interests, please read! [was Re: T1] Followup-To: poster Date: 12 Jul 1995 13:03:44 GMT Organization: University of California, Berkeley Lines: 225 Message-ID: <3u0h7g$hb6@agate.berkeley.edu> References: <3tu6q6$num@news.bu.edu> NNTP-Posting-Host: violet.berkeley.edu In article <3tu6q6$num@news.bu.edu>, Mikhail Teterin <mi@cs.bu.edu> wrote: >Is there a support for T1 in FreeBSD? Are there any >commercial drivers ported? Thanks for ANY hint! There's the Cronyx/Sigma sync ppp card, but I'm not sure what its top end speed is.. I don't believe that we have anything currently capable of doing T1 right out of a FreeBSD box. That said, I have 2 ARNET SYNC/570i cards here - one two port and one four port - and they'll do up to 5Mb/sec. All I'm lacking is a driver! The main chip that needs to be dealt with here appears to be the Hitachi HD64570, so if anyone out there has prior programming experience with this then I'm definitely interested in hearing from you! ARNET has graciously loaned me these boards for the express purpose of pressing them into some skilled programmer's hands, but such hands have proven to be a little harder to find than I had hoped.. :-( I'd therefore like to put the following proposal to the various ISPs and others with an interest in mid-speed comms out there who might be reading this message: If those of you who are truly interested in seeing a driver written for the ARNET SYNC/570i (which does, by all appearances, seem to be a slick little card and good value for money) would care to contact me, I'll be willing to do the legwork of trying to organize a cooperative effort. What this means, essentially, is that those who contact me should also be willing to donate something reasonable in the way of time, money or manpower to the project. They should also be willing to see the results released for general consumption with an unrestrictive (e.g. "BSD style") copyright. But please, read on. Some might consider the concept of a group of erstwhile competitors working together to produce a common product which will then be _given_ away to be somewhat naive, but I don't see it that way. I see it instead as a natural progression for a lot of things that have been going on in the free software camp up to now. Consider this: The decision to run FreeBSD (or any other free OS) in a business or other critical-use scenario is certainly not one that people are making lightly. In the beginning, many in fact started out with very tentative exploratory steps and regarded FreeBSD with some suspicion, but as they gained greater trust in the quality of the system and saw that its core developers had been around for a couple of years and showed every sign of being around for a couple more, they made a greater committment to it. Most importantly, they took this chance largely because they perceived the project as having a *future* and not about to just drop dead in 6 months, leaving its new users high and dry. This is the essence of any good relationship and you're hardly going to buy a database or spreadsheet from a vendor you've heard might be filing for bankruptcy next week; you want someone with a strong product and a promising future. A growing number of people have displayed such a degree of confidence in us, and for that we're certainly gratified, but not without certain fears. To clarify this, in the corporate world a healthy company is usually judged by the consistency of its quality, its ability to innovate and its overall profitability. FreeBSD, free or not, also gets measured by these same standards of consistency and innovation, it's unfortunately just not very profitable. :-) That non-profit aspect may be more politically and spiritually desirable but it does have some significant drawbacks, one being that there's no capital to expend on increasing the consistency of product quality or funding continued innovation like the "real company" does, thus requiring that these improvements happen by other means. With that in mind, it begins to make more sense that the various FreeBSD users, both commercial and non, should want to band together more closely and without regard for of any kind of external competition. We, and that's all of us now - the users and the project contributors - really do share common ownership of this "product" called FreeBSD. It may seem at times like the FreeBSD core team thinks it owns it, but it certainly never did and never will. The FreeBSD core team is essentially just a group of custodians over a freely available collection of BSD and GPL licensed sources. No one really "owns" it in the true sense anymore and whomever last changes something gets a corresponding measure of unofficial responsibility for it, no more no less. If you couple this with the fact that the FreeBSD Project itself has no real resources of its own, except perhaps for a common code base and a couple of machines with sources on them, then it quickly becomes clear that to really increase the quality and coverage of FreeBSD's feature set in the same period of time that a commercial OS vendor would (if not faster) then something more has to happen. Well, a good start would be some greater degree of understanding among the FreeBSD user populace of the fact that the FreeBSD source tree itself is a *shared* responsibility. We all share the process of making it viable in the long term, and if the quality and quantity of contributions stagnates then the project itself dies. Things have fortunately been quite the opposite so far, with almost more contributions coming in than we can handle, but that's certainly not a good rationale for getting complacent and there are certainly a lot of things that still need to be done! There really isn't such a thing as a free lunch, and FreeBSD is, unfortunately, no exception. A company that deploys FreeBSD on 20 internal servers may have saved over $1-2K a pop in the purchase of the software, but there will come a time when those 20 servers will suddently have a need to route IPX, or accomodate the addition of a T1 connection, or do any number of things outside of FreeBSD's performance envelope at the time. When and if that time comes for them, they'll then have several options: One option is to issue a fervent plea on the net in hopes that someone else has already done whatever it is they need. This sometimes works, though it has a fairly low success rate and relies on the fact that somebody somewhere is still interested in doing public work. Another option is to hire someone "off the street" and try to pay them as little as possible to hack it into their system. This also sometimes works, though what's left is a legacy that may break in the face of subsequent changes to the system and with the attendant risk that the guy they hired off the street may suddenly move to China. For small or highly custom changes this is still probably the way to go, but for larger projects it's not an option with much long-term viability. The third option, and one I prefer for projects of significance, is for them to try doing it "the free software way", which is to say cooperatively with as many other like-minded people as seems practical (which may be as small as 2-3 developers during the initial stages). Some project members may elect to donate equipment, funds for purchasing such equipment (or paying an external engineer) or a full or part-time engineer themselves. It would be the job of the project coordinator (either inside or outside the project) to match donations with the needs of the task and see that it reaches completion in a reasonable period of time. Some tasks, like supporting a certain board or software package, will be small and probably fly for less than $1K total investment. Others, like implementing generic sync ppp support and drivers for a whole family of T1 cards, might cost the participants $15K or more (cards, test rig, a short engineering contract to write the code, etc). Whether big or small, however, if that cost is shared and those involved can write it off as a development expense then it's not as big a deal as it seems at the start. Even assuming a $20K cost for developing a new T1 routing solution (and that's high), if just 4 companies agreed to share equally in the costs of development then that'd only be $5K to each, a very managable one-time cost and that's without even factoring in the other useful side-benefits. The side benefits are many: Each company gets full source for its $5K (assuming that the code in question wasn't proprietary, in which case more specialized arragements would be made) and an army of free Quality Control engineers on the net. The benefits of having several hundred people punish your code in various ways also shouldn't be underestimated, and it almost always makes for a far more polished product in the long run. Another not-insignificant benefit is that by working within the context of the FreeBSD project you're also helping to keep the spirit of innovation within the project alive, helping to preserve the value of your "investment" in FreeBSD. As a "clearing house" of sorts for things like this, I have formed a corporation by the name of "FreeBSD, Inc." It is a not-for-profit enterprise dedicated to furthering the cause and quality of FreeBSD and it gives other commercial entities a real organization to deal with rather than having money and equipment disappear to a variety of uncertain destinations. Over the course of the next several months, FreeBSD, Inc. will be releasing a number of details of its plans and currently active projects, some of which already have money and equipment donated but are stalled in need of development resources. Though I'm still in the process of drafting FreeBSD, Inc.'s various charters and bylaws, the corporation itself does exist and can begin coordinating various such efforts now so there's no reason for additional delay. As a quick indication of what I'm talking about, here are two example projects that have been sort of slowly simmering for awhile now: 1. Sync serial project Status: On hold Current Assets: 2 ARNET SYNC 570/i boards and specs. Requirements: 1 full or part-time engineer. Should have driver experience, experience with the Hitachi HD64570 a definite plus! Also required is one ISP with a semi-immediate need for T1 who can serve as the initial customer. Options: Donation of engineering resource or funds to hire. 2. SMP (Symmetric Multi-Processing) Status: Very slow development Current Assets: One ASUS P54NP4 dual-P590 based development system Requirements: At least one full-time engineer. Should have MP or low-level systems programming experience, prior experience with adding SMP support to a UNIX kernel a definite plus. Several testers with other types of Intel MP spec compliant hardware. Options: Donation of engineering resource or funds for fairly long-term hire (1yr min) of skilled engineer. Would prefer donation of engineering resources. The difference between either of these two projects sitting endlessly on the vine or suddently becoming tangible reality is actually quite small, and really comes down to enough people deciding they want something enough to start talking with FreeBSD, Inc. (e.g. me) about how to get it. I'll then see if the right ingredients can be brought together to make it happen and respond with a "yes" or "no". If enough people contact me about some task that they feel to be important then I'm also always willing to consider it, time and resources permitting. I'm pretty open to what the corporation does with itself just so long as what its doing is self-sustaining (e.g. any projects it's engaged in have some sort of sponsorship) and of general benefit to the project as a whole. I think that we can do a lot with FreeBSD and I furthermore believe that we can do a lot of things that the critics may never have expected us to be able to do. It's all down to a little vision and some willingness to be cooperative in carrying it out. So if there's something you want out of FreeBSD that it's just not giving you, you think there are a number of people who feel the same way and you think that you'd be willing to throw a little time or money into a pot in with the others, then contact us! If we think something is both worthwhile and possible then we'll do our best to make it happen. Current address: FreeBSD, Inc. 4041 Pike Lane, #D Concord CA, 94520 Phone: 510-928-8380 FAX: 510-674-0821 Email: inc@freebsd.org Jordan