Date: Tue, 19 Sep 2000 22:27:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@freebsd-uk.eu.org (j mckitrick) Cc: tlambert@primenet.com (Terry Lambert), brett@lariat.org (Brett Glass), chat@FreeBSD.ORG Subject: Re: Learn from History, please (was Re: new license idea?) Message-ID: <200009192227.PAA14621@usr02.primenet.com> In-Reply-To: <20000919195026.A72836@dogma.freebsd-uk.eu.org> from "j mckitrick" at Sep 19, 2000 07:50:26 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> A few questions (you knew they were coming ;-) > > 1. If a company has no real competitors for a product, how can they be > marginalized? Suppose a BSD licensed digital paint program > appeared, and a company used the code and extended it to a proprietary version > especially suited to photograph processing. Suppose they kept the changes to > the code, and no competitors appeared. How would they become marginalized? > Simply because of the maintenance pressures of continuing to merge current > changes from the open source branch with their own? By virtue of people who want the features of the proprietary product deciding to add them to the open source version, one at a time, rather than paying for it. Consider that other people will be adding other code to the open source version, which people may demand in the proprietary version as well -- and not understand why the features are slow in coming. From another tack, we might consider that someone who needs an image processing program might not need the full capabilities of the commercial version, but have bought it for support or other reasons (yes, I have been known to buy software). For example, I know someone who recently bought "Stronghold"; the reasons for the capital outlay for it were (1) making Apache work with OpenSSL and RSAREF was not worth the time it would cost to learn about it, and (2) to get a certificate. It's pretty obvious that a certificate could have been had at a fraction of the cost, without the server cost included. Going back to our image processing software user, we look at features coming out in the open source version that are enticing to the user, who does some photographic processing, but uses the program more than half the time just as generic image processing software (the same way I use the copy of Adobe Photodeluxe 4.0 Home Edition that came with my Sony laptop). As time goes on, the vendor will find themselves with only their core of power users who don't need to do things outside the boundaries of the limitations inherent in the product; or in other words, they will find themselves marginalized into a niche market that will, if they are not careful to follow the open source developements, turn into a legacy market. > 2. Using the illustration of the two firewall companies, how > could Company B remain profitable after opening its source? This is a two-parter, so I will answer in two parts. The trite answer to the first part is "By not opening _all_ of its source". This really means letting go of the tactical in order to concentrate on the strategic; this is hopefully (from the point of view of the V.C. funding or the shareholders) a core competency that they bring to the table. An example from recent BSD history is Soft Updates. Whistle paid Kirk (and Julian and, much less, me) for the time to develope the code for FreeBSD, in order to get around the need for a UPS in the InterJet. Kirk was bound to keep the code from being commercially utilized by direct competitors for the time that Whistle thought it would take to recoup R&D costs. After that, the code quit being strategic, and became tactical. We could add in a marketing dimension as well: if a competitor started using the code after it became tactical, then we could point to our lead on the technically as a marketing strategy. So in that sense, releasing the tactical code could actually have more strategic value, whereas keeping it under wraps would have zero additional strategic value. > Does the concept of strategic victory include getting your > foot in the door (or your code in the tree) at the expense of > short-term profits? This is a hard one to answer. On the one hand, you have all of these "Internet Companies" or "dot coms" who are burning huge amounts of cash to acquire customers, and damn the consequences. One of the consequences for most of them is a separate "burn rate" from the normally considered one of cash: I call it "customer burn rate". What it amounts to is whether you in fact achieve anything lasting in terms of a customer relationship. For most of the "dot coms" that are failing in recent history, I think the answer is "no". So if "getting your foot in the door" is your goal, then you are probably doomed, no matter what your approach. I really like to use a different analogy: "getting the camel's nose into the tent". The point is to try to _maintain_ the relationship, long term, in a sustainable way. I think that long term, "portal plays" are pretty much doomed. Look at Yahoo jilting Inktomi for their new search engine technology: things in the Internet space are fickle. There is really no such ting as traditional "brand loyalty" or "frequency marketing", although some people are trying real hard to find ways to address this. The best bet so far seems to be the "sticky application"; the theory is that you get a webmail or other application account, and then you come back. But when you come back, you are returning for the freebie, so it's still a game of selling your eyeballs to advertisers. I think that most ASPs are going to flounder and crash, if they attempt a different model that doesn't take what;s out there for free into account, and deal with it somehow. So after all that, "yes, if you can get the camel's nose in the tent, it is worth the short term profit to ensure the ongoing long term revenue stream". But doing that is a trick with a hole in it -- that is, it is not something that you can put into a formula, turn a crank, and have a succeful Internet based business (or even a successful "brick and morter" based business) pop out, like Athena from Zeus' head. > 3. Do any of these arguments apply differently to separate > apps than to operating systems? Less so. I recently spent several months integrating 30 or so open source packages into a single entity. I ended up with about 3.1 million lines of code that would compile on FreeBSD or AIX with the same set of Makefiles, and could target a distribution/installation directory seperate from where these things normally wanted to install (and clobber system parts, each other, and, in general, make a mess of trying to install security patches that applied to the components being replaced, etc.). I'm very good at this type of work, if I do say so myself, as I am very detail orients: everything must function exactly right, or I'm not happy with it. Most kernel hackers of any ability would probably be damn good at it too, if they could find the patience. That said, I did a smaller, but similar, project in less time (2 months) and with a team of myself and several part-time people who mostly worked on other tasks. It was only about 1.8 million lines of code. IBM Global Services (IGS) were willing to so the same work, but with two architects, a team of almost a dozen total people, and estimated 8 months. As I said, I'm good at this type of work, even if it is mostly sanding and glueing. The point to this is not self aggrandizement, but pointing out the flaw in approaching applications the same way. Geoffrey Moore (of Regis McKenna fame) likes to proselytize about "whole product" strategies. If you were selling an application based on open source, there is a huge amount of work you would need to engage in before you had a whole product (or, as in the case of my code, a whole service). > 4. I am a bit unclear on this paragraph: > > | So the claims of fragmentation risk are really exagerated; they are, > | in fact, FUD. One does not need a license to protect one from a > | fragmentation or a code hijack, unless the code is strategic, in > | which case, one is better off not revealing it at all, since it is > | easy to read with one hand and type with the other; not only easy, > | but the economic pressures in Silicon Valley have raised it to a > | fine art, to the point of having its own name: "clean rooming". > > Do you mean that a really good 'secret' or innovation is best > protected by not releasing it at all, at least for a time? Yes. This is why I think the best method of "promoting progress in the arts and sciences", at least as regards computer science, is to get rid of patent and copyright protection on software, and replace it with a much shorter duration protection, similar to patents, but requiring source escrow, and precluding litigation following the escrow period (after which it would become public domain). I wouldn't make it last over 7 years, under any circumstances, and would prefer 2 years as a default, unless the applicant could show a longer R&D period (after which, it would be limited to the documented R&D period or 7 years, whichever is less). > Or is there an additional meaning? No. > And what is "clean rooming"? 1) Bob tests the code to determine its behaviour 2) Bob documents the behaviour (entry points, etc.) 3) Bob is paid, and never hear from again 4) Tom takes a test to ensure he has never seen the code or worked with it (this is called a "virginity test") 5) Tom build code that does the same thing, using Bob's documentation 6) The code is released, and competes with the original code that Bob documented This is how Compaq was able to claim 100% compatability, after "clean rooming" the IBM PC BIOS for their clone machines; as an example, Compaq considered this code strategic, because of the high barrier to entry for competitors, and their ability to undercut IBM's prices. Then companies like Phoenix got into the business, and now a BIOS is a commodity (tactical: you buy it from the lowest bidder who can meet your software requirements). 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?200009192227.PAA14621>