may the force be with you

Agrodiaetus butterfly, Harvard University" The butterflies' wings offer clues to speciation

Why one species branches into two is a question that has haunted evolutionary biologists since Darwin.

Given our planet's rich biodiversity, "speciation" clearly happens regularly, but scientists cannot quite pinpoint the driving forces behind it.

Now, researchers studying a family of butterflies think they have witnessed a subtle process, which could be forcing a wedge between newly formed species.

The team, from Harvard University, US, discovered that closely related species living in the same geographical space displayed unusually distinct wing markings.

These wing colours apparently evolved as a sort of "team strip", allowing butterflies to easily identify the species of a potential mate.

For me, this is a big discovery just because the system is very beautiful Dr Nikolai Kandul, Harvard University

This process, called "reinforcement", prevents closely related species from interbreeding thus driving them further apart genetically and promoting speciation.

Although scientists have speculated about this mechanism for years, it has rarely been witnessed in nature.

"The phenomenon of reinforcement is one of the very few mechanisms that has natural selection playing a role in speciation," said Harvard co-author Nikolai Kandul. "It might be very widespread but it is hard to find good evidence of it."

Geographical isolation

For speciation to occur, two branches of the same species must stop breeding with one another for long enough to grow apart genetically.

The most obvious way this can happen is through geographical isolation.

Agrodiaetus butterfly, Harvard University" The butterflies choose mates with similar markings

If a mountain range or river divides a population of animals for hundreds of generations, they might find that if they meet again they are no longer able to breed.

But geographical isolation is not enough to explain all speciation. Clearly, organisms do sometimes speciate even if there is no clear river or mountain separating them.

The other mechanism that can theoretically divide a species is "reproductive isolation". This occurs when organisms are not separated physically, but "choose" not to breed with each other thereby causing genetic isolation, which amounts to the same thing.

Reproductive isolation is much hazier and more difficult to pin down than geographic isolation, which is why biologists are so excited about this family of butterflies.

Butterfly clue

The Harvard team made the discovery while studying the butterfly genus Agrodiaetus, which has a wide ranging habitat in Asia.

The females are brown while the males exhibit a variety of wing colours ranging from silver and blue to brown.

Dr Kandul and his colleagues found that if closely related species of Agrodiaetus are geographically separate, they tend to look quite similar. That is to say, they do not display a distinctive "team strip".

Agrodiaetus butterfly, Harvard University" Scientists are excited about this new research

But if similarly closely related species are living side-by-side, the researchers noticed, they frequently look strikingly different - their "teams" are clearly advertised.

This has the effect of discouraging inter-species mating, thus encouraging genetic isolation and species divergence.

"This butterfly study presents evidence that the differences in the male's wing colouration is stronger [when the species share a habitat] than [when they do not]," said the speciation expert Axel Meyer, from Konstanz University in Germany.

"This pattern would therefore support the interpretation that it was brought about by reinforcement, hence natural selection."

The reason evolution favours the emergence of a "team strip" in related species, or sub species, living side-by-side is that hybridisation is not usually a desirable thing.

Although many of the Agrodiaetus species are close enough genetically to breed, their hybrid offspring tend to be rather weedy and less likely to thrive.

Therefore natural selection will favour ways of distinguishing the species, which is why the clear markings exist.

"For me, this is a big discovery just because the system is very beautiful," said Dr Kandul. "As much as we can we are showing that [reinforcement] is the most likely mechanism."

This research was published in the latest edition of Nature magazine.

# posted by dark master : 7/24/2005 05:30:00 PM  0 comments

19 Jul 2005

The FreeBSD operating system is the unknown giant among free operating systems. Starting out from the 386BSD project, it is an extremely fast UNIX®-like operating system mostly for the Intel® chip and its clones. In many ways, FreeBSD has always been the operating system that GNU/Linux®-based operating systems should have been. It runs on out-of-date Intel machines and 64-bit AMD chips, and it serves terabytes of files a day on some of the largest file servers on earth.

The Berkeley Software Distribution (BSD) family of operating systems can be traced back to the BSD UNIX operating system created and maintained at the University of California, Berkeley, since the late 1970s. Today, the BSD family consists of five main branches, and even Linux activists, comfortable with a plethora of distributions, find themselves bemused by the number of BSD flavors appearing in ever-greater numbers. Since 2001, when the last major branch -- DragonFly BSD -- was launched, FreeBSD, OpenBSD, NetBSD, and Mac OS X represent a new creative surge in the UNIX world. All of them are POSIX-compliant. All present similar command-line interfaces to their users. All use kernels and system libraries that make similar programming models and application usage characteristics possible.

For legal reasons, BSD cannot be called a UNIX system, but it is widely accepted that the BSD flavors represent open source UNIX. Amazingly, in the late 1980s and early 1990s, no free operating system worth the name running on the PC or Mac was available. UNIX lived on mainframes and the Scalable Processor Architecture (SPARC). Proprietary UNIX companies had balkanized the commercial UNIX scene.

In the beginning, there was 386BSD

In 1993, two events occurred that were to change the UNIX scene permanently: The NetBSD group was founded, and the 386BSD patch kit was revived. Ten years before, BSD UNIX developers had been recruited from the ranks of U.C. Berkeley staff and Ph.D. students; the money had largely come from the Defense Advanced Research Projects Agency (DARPA), but the funding was coming to an end. The 386BSD project came into being in 1985 as an attempt to get BSD UNIX to run on an Intel chip. The first release did not occur before 1989, and for various reasons, the project ended up becoming a reference operating system publicized by Dr. Dobb's Journal in July 1992. Known as 386BSD 0.1, it experienced 250,000 downloads.

The 386BSD was mainly based on Bill and Lynne Jolitz's ideas to improve the very concepts on which UNIX was based. It was meant to be free, but supporting a complete operating system virtually on their own proved to be beyond the Jolitzes. The system lost out to the armada of programmers joining an almost unknown Finnish student help build Linux.

The history of FreeBSD

Another group that took the original vision of porting BSD UNIX to the Intel chip to its conclusion formed in the course of 1993. Relying on previous work by Bill Jolitz, FreeBSD V1.0 was released in December 1993. Jordan Hubbard, the project leader, drove the project, managing infrastructure and a group of committers that grew to 200 developers by early 1997. FreeBSD is supposed to reach version 6.0 by the end of this year and is arguably the most important of all free UNIX systems. FreeBSD is not a UNIX clone, but rather a system that not only works like UNIX but whose internals and system APIs are UNIX-compliant.

FreeBSD is not the Intel-/AMD-only system it once was. It also runs on SPARC64 machines and has a fairly long history on Alpha architectures. If a BSD user is interested in the chips running Mac OS X, he could switch over to Darwin OS, the open source core of Mac OS X, which in turn relies on much of FreeBSD V5.0 and its successors. NetBSD, of course, has been running on all Mac architectures since 1995.

Back to top

What FreeBSD does and Linux doesn't

BSD on the Mac BSD on the Mac is old hat. UNIX has been running on Mac architectures for even longer. Hardly anyone remembers it these days, but there was a time when a version of AT&T UNIX ran on Apple's Quadra machines. In the late 1980s, this UNIX version was known as Apple UNIX, and it represented Apple's bid for a part of the UNIX server space. Apple UNIX was never ported to the newer PowerPC architecture, but it ran well enough on Motorola 68x00 chips. Obviously, the code was proprietary, usually requiring a low four-figure monetary investment. We might take comfort in the fact that even a luminary as exalted as Bill Joy was dismissing the Mac in the mid-1980s as a machine no one in the UNIX world cared about. Oh well. When 386BSD came along in 1991, Mac was not far off some peoples' minds. Brad Grantham, Lawrence Kesteloot, and Chris Caputo managed to port 386BSD to the Mac under the name MacBSD. In late 1992, BSD UNIX had found a new home on a Mac II, although the concurrent breakup of BSD UNIX was beginning to be seen at the time as a necessity, rather than a possibility: The legal shenanigans around AT&T and U.C. Berkeley had made the freeing of the BSD UNIX project a technical as much as a legal necessity. It is still remarkable, though, that an early Macintosh architecture ran free UNIX before the Intel chip had a BSD flavor dedicated to it. 386BSD was never meant to do much except suggest which UNIX should go on the Intel chip. It didn't work very well at the best of times and never really reached version 1.0. In the summer of 1993, Allen Briggs and Michael Finch started to merge NetBSD V0.8 and MacBSD to avoid balkanization before it became a serious issue. After all, the UNIX wars were fresh in everyone's mind, and NetBSD seemed a worthy project for trying to incorporate as many architectures under the BSD mantle as possible. By the time NetBSD V1.0 came around, the NetBSD/mac68k project was firmly established, and it has been going strong ever since. The NetBSD/macppc project is of more recent vintage. The PowerPC port was included among the NetBSD ports in 1999, although all post-1995 PPC architectures are included. It supports all Mac architectures since the 604 PowerPC. OpenBSD/macppc is based on NetBSD code, although it took the OpenBSD project a little longer to have a fully functioning port. For obvious reasons, the FreeBSD project remained aloof, focusing instead on Intel and AMD support, although FreeBSD code has been running on Macintosh architectures since Darwin -- the OSS kernel of Mac OS X -- was released. This seems less relevant these days, as Apple has announced Intel support. But there is considerable overlap between FreeBSD and Darwin development, and quite a few FreeBSD developers are Apple employees.

FreeBSD is an operating system, not just a kernel. This statement does not mean quite as much as it used to, however, because the very notion of a kernel is fairly arbitrary. In a UNIX context, it means that users can't access certain libraries and executables after booting has finished. The kernel manages the hardware for applications, even though today many UNIX-type operating systems would give user-level threads a role in managing kernel resources. You can safely assume that anything users cannot access during run time is part of the kernel. This does not mean that users can't influence kernel behavior. Certain utilities can report and tune memory management, for instance, and they are definitely within the purview of the user. These utilities communicate through the system's API, which is not part of the kernel, although it is quite clearly part of the operating system. FreeBSD, of course, includes all these and many other utilities and applications that deal with the characteristics of networking and hardware.

If you were to compare the contents of a complete Linux kernel download and a FreeBSD download, there would be much that the downloads have in common. Both have IP stacks, memory-management routines, file system implementations, and so on. The file system hierarchy has demonstrably similar origins, and most command-line applications have identical names and similar command-line semantics. The actual implementations look somewhat different, of course, but you would still be able to see that both systems have similar conceptual origins. A major architectural difference lies in the way FreeBSD reads and writes files to the so-called buffer cache, which (strictly speaking) does not even exist as an entity separate from virtual memory. Linux has always managed buffer cache sizes automatically, but its memory-management routines work differently from FreeBSD's.

Back to top

Ports and file systems

FreeBSD works immediately after it has been installed. It works because a FreeBSD system installs a working system using the FreeBSD installer, also known as sysinstall, and it uses a package-management system that has clear UNIX origins. But FreeBSD goes much further than that: Package management has been thoroughly streamlined; binary and source packages are not subject to the whims of the package-management system de jour, an affliction common to Linux distributions. FreeBSD integrates package management and Internet-wide updates with the Ports system, allowing you to address source download and compilation in one procedure. One could argue that Debian has similar advantages, but one should not forget that Debian is an operating system whose reliance on the Linux kernel is accidental. The Hurd and the NetBSD kernel would work just as well, provided the Debian project remembers to update the packages.

The FreeBSD file system is also somewhat reminiscent of its BSD UNIX past: It comes under the Fast File System (FFS) and the UNIX File System (UFS) monikers. Users are more likely to interact with the FFS portion of the file system, which regulates file and directory access. The UFS system, version 2 of which was released in 2003, sets the file system limits and the basic data structures organizing raw disk access. UFS and FFS are also available on NetBSD and OpenBSD. The more well-known journaling file systems current on Linux, like Reiser File System (Reiser FS) and Journaling File System (JFS), are not available on FreeBSD, mostly for security reasons. UFS has the additional advantage of stability and (now) scalability because its behavior and performance rely on research dating back more than two decades.

Back to top

Security and compatibility

Other benefits can influence your choice to take FreeBSD more seriously. Although not in the same league as OpenBSD with regard to code-level security, FreeBSD comes with a formidable array of security mechanisms that work out of the box. Since FreeBSD V5.0, it is possible to add fine-grained access controls and security policies that have their origin in the DARPA-funded TrustedBSD project. FreeBSD supports access control lists (ACLs) and mandatory access control (MAC) modules. The latter is of course accessible only to systems administrators and managers, but it enables small businesses to run networks with fine-grained security measures that apply to subsets of the system exposed to the outside world. UFS V2 has excellent ACL support via extended attributes; you must configure UFS V1 separately if ACLs are a requirement.

If you have been introduced to the mysteries of Linux, you might be concerned to see applications available for, say, SuSE Linux and Mac OS X, but have no separate source or binary for FreeBSD. FreeBSD is able to run a Linux binary compatibility module, which you must enable at installation time or from the command line. Linux run-time libraries might be required, as well, but you can add them from the Ports collection.

Of course, FreeBSD runs all major X Window System-based desktop shells, such as the KDE desktop and the GNU Network Object Model Environment (GNOME) desktop. FreeBSD used to be the desktop user's UNIX version of choice until the FreeBSD-based OS X came along. It still gives UNIX users operating under budgetary constraints an extremely good deal and does not require additional licenses when configured as a server or a client.

Back to top

FreeBSD derivatives

Like most operating systems with a long history, FreeBSD has generated its fair share of offspring. It is possible to start a FreeBSD system from a CD without having to compile and produce a CD. The work has already been done with the fairly mature Free System Burned in Economy (FreeSBIE) V1.1 LiveCD system, which in turn is based on FreeBSD V5.3. If allocating part of the hard disk and writing to the master boot record (MBR) seems risky, it is a perfect starting point to begin testing FreeBSD.

DragonFly BSD is based on the FreeBSD V4.x series release, but it does not aim at the average user at all. It mentions secure Internet-wide clustered file systems on the first page of its Web site -- not a requirement likely to trouble first-time UNIX users. DragonFly BSD was founded by the resident FreeBSD virtual memory guru and tries to implement a completely new approach to massive secure file system and memory management.

Back to top

Documentation matters

It is unusual to mention operating system documentation that comes with UNIX systems because such documentation tends to be as unreadable as it is intrinsically interesting and useful. FreeBSD documentation is a great exception to this rule because it does not pay much attention to old-style manual pages or copy the style or organization of UNIX documentation.

FreeBSD documentation is available as a concisely written book, on the Internet and on paper, covering each and every aspect of the system in a pleasant and considered style. It does not presuppose much familiarity with UNIX systems and, indeed, has been used profitably by UNIX neophytes. It does teach the miracle of a simple FreeBSD installation, but it also gives a clear introduction to the whys and wherefores of FreeBSD kernel compilation or securing a FreeBSD installation. It is interesting to see what the documentation omits -- for example, Perl and Apache -- and what it includes -- such as the Berkeley Internet Name Daemon (BIND) and the FreeBSD-specific storage manager Vinum. Vinum implements virtual disk drive management and can cope with RAID 0, RAID 1, and RAID 5.

Back to top

The administrator's operating system

It is possible to describe FreeBSD as a network administrator's operating system: It's fast, SMP-capable, and well integrated with a large number of networking tools. However, FreeBSD is just as slick and fast when run on laptops, when running office applications, and when running mail clients and databases. Its installation routines are simple enough for a Microsoft® Windows® power user to be comfortable with. It also has a lot to offer to Linux users, simply because in binary-compatible mode, applications native to Linux run without changes. FreeBSD is extremely scalable and runs most applications written for Linux or BSD flavors. Don't assume that FreeBSD is a Swiss army knife among free operating systems, though: It's neither as secure as OpenBSD nor as scalable as a future Open Solaris version can be safely thought to be. But it competes with any operating system -- commercial or free -- on the Intel chip and, in many cases, provides a more stable and scalable platform than any of its nearest competitors.

Back to top

Resources

• FreeBSD is the main FreeBSD portal. It provides access to the source code, the FreeBSD handbook, and new FreeBSD versions.
  
  
• To delve into the beginnings of FreeBSD, the 386BSD site gives an account written by Bill Jolitz. 386BSD source code is available from this site, as well.
  
  
• Although used widely, UFS 2 is not well known.
  
  
• The DragonFly BSD Project has substantial and technically demanding documentation.
  
  
• FreeSBIE provides a live FreeBSD version on CD.
  
  
• The Debian operating system is commonly thought to be GNU/Linux-based, but as you'll see when you look on the Debian Web site, it can run other kernels as well, like NetBSD and Hurd.
  
  
• For those who like to go back along the Mac timeline to Motorola 68k-based architectures, the NetBSD/mac68k Web site provides large doses of fun.
  
  
• The PPC port for NetBSD is represented by the very active NetBSD/macppc group.
  
  
• OpenBSD's focus on security has found friends among Mac specialists and the PPC port is developed here.
  
  
• Hard disk management is often dominated by commercial tools, but FreeBSD comes with its own OSS tool called Vinum.
  
  
• Berkeley UNIX was the original test bed for IP networking. BIND, or the Berkeley Internet Name Domain, represents an implementation of all DNS protocols, including name server and resolver library, without which the Internet domain name infrastructure is impossible.
  
  
• See the developerWorks tutorial "Installing FreeBSD" to learn how to make FreeBSD run on your computer.
  
  
• Learn security tips by reading the developerWorks article "Improving the security of open UNIX platforms."
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  

Back to top

About the author

Frank Pohlmann dabbled in the history of Middle Eastern religions before various funding committees decided that research in the history of religious polemics was quite irrelevant to the modern world. He has focused on his hobby -- free software -- ever since. He admits to being the technical editor of U.K.-based Linuxuser and Developer and came to FreeBSD via a strong interest in UNIX kernel internals and an interest in Linux applications for writers and artists.

# posted by dark master : 7/24/2005 05:26:00 PM  0 comments

Now, in reality, it isn't possible to have one without the other, but this bank inventoried the real stock and sold these synthetics, which were really contracts to pay you as if these things really existed. These synthetics were traded independently. It isn't too difficult to see that, if you looked at the price for buying the prime plus the price for buying the score, it should equal the price of buying AT&T stock. That is to say, if you bought the stock, you would get the stock with the dividend. If you bought the "stock without the dividend" and the "dividend without the stock," the sum should be the "stock with the dividend." Because they traded separately, sometimes they would get out of sync, and you could make money buy buying the cheap one and selling the expensive one. This activity--looking for price differences between two things that ought to be exactly the same--is called arbitrage.

The reason "rocket scientists" (physics majors) were in such demand on Wall Street in those days is because physicists spent their time breaking down what appeared to be elementary particles (such as neutrons) into subcomponents (protons, electrons, and neutrinos) that might not even exist as independent particles (quarks)--except they did it theoretically. Financial engineers like to look at the price of something that appears to be an elementary particle and break it down into possibly imaginary components, which they can price separately and then see whether it all adds up.

How might that work with, say, an Apple computer? A 17-inch iMac was $1,499 at the Apple store the last time I checked. You can purchase an extended warranty, AppleCare, for $169. That warranty is for years two and three; year one is included. AppleCare also includes extended telephone support, but I'm going to ignore that for now to simplify things.

After a quick trip to Wikipedia's page on failure rates (leavened with anecdotal rumors), it is not unreasonable to suppose that computers experience more failures in their first year than in the subsequent two years. The overall failure rate for computers runs about 15 percent--Macs do better than average. Still, it is not unreasonable to suggest that the curve looks roughly something like 8 percent failure in the first year, 4 percent in the second, and 2 percent in the third. That means the first-year warranty is worth about $225. So really, that 17-inch iMac costs $1,274 for the computer and $225 for the first-year warranty.

But wait, there's more. Because consumer sites tend to be leery of extended warranties, I initially balked at buying AppleCare, but I learned that I had the option to buy it anytime during the year. However, once the warranty expired, so did the option.

Apparently, along with my computer and its warranty, I was also buying a one-year call option on AppleCare. What's that worth?

In 1973, Myron Scholes and Fischer Black developed a model for how to price options, which revolutionized financial markets. The trickiest input into the formula, and one that has a significant impact on the result, is the volatility of the price of the underlying asset. If there is no volatility (that is, the price doesn't ever change), then the price of the option is really just the interest rate discount for not having to buy it right away. Things get more interesting when the price fluctuates.

In the case of AppleCare, the price doesn't change. For a 3 percent interest rate, the value of that option should be around $5.

Still, logically, that iMac pricing is really a $1,269 computer, a $225 one-year maintenance contract, and a $5 call option on an extended warranty. (For the record, 360 days after I bought my Mac, I exercised the option and bought the extended warranty.)

Let's try to apply similar thinking to software licenses--in particular, enterprise software licensing. We can break down what appears to be a price for a single "asset" (the software license) into its component "quarks."

The conventional wisdom is that you buy a software license (the value of the actual software bits), and then you buy maintenance and support separately, which usually costs 20 percent of the original license cost annually. For a $1,000 software license, you'll pay $200 per year for maintenance and support.

What happens if we decide to separate the "stock" from the "dividend"? Could we price the "software without the maintenance" separately from the "maintenance without the software"? It's much the same as with that AT&T stock--even if logically the dividend always comes with the stock, a middleman might be able to sell them separately.

Now, in this case, the maintenance and support is already priced separately from the license. Doesn't that mean we're already done? Perhaps. Let me suggest that even though you're buying and paying for the maintenance separately, there is an option embedded in the license. When you buy the software license, it includes "options" to buy maintenance. (I use options in the plural, because I'll look at an option for each year of maintenance.) Let's separate that out. That is, we want to price the license without the options to buy maintenance and the options to buy maintenance.

When I informally polled enterprise software buyers about what they would pay for software given that they wouldn't be able to buy any maintenance for it (as a middleman, I'd be selling that to somebody else), the universal response was that they would pay much less than the license--implying that the option to buy maintenance was clearly a significant fraction of the price. It is also the case that people expect software maintenance prices to be subject to change. Certainly, it has been the historical record that large software companies do change their pricing on maintenance occasionally--sometimes substantially.

How then to quantify the volatility of maintenance prices? Let's try a shortcut. It turns out that over the last year, the implied volatility of the Nasdaq (there are options on the Nasdaq index) has been running about 30 percent. We'll use the implied volatility of the Nasdaq as a proxy for the volatility of software prices--under the theory that the volatility of the Nasdaq captures in some way the volatility of pricing in the tech world. This is as good a place as any to start; we'll come back to the implications of alternative values in a few paragraphs.

Let's normalize the values to a $100 software license and say that a one-year option has a $20 underlying price; a year of maintenance is 20 percent of the license, so we'll assume it's worth $20 today. The strike price (what you can buy it for in a year) is also $20--a 5 percent risk-free rate. With all of those inputs, the value of that option is about $2.85. That is to say, for $2.85 you can lock in the price of the maintenance contract so that one year from now, you'll have the right to buy it for $20.

The right to buy the same maintenance for $20 two years from now is about $4.25; three years is $5.35; four years is $6.35. That takes us five years out. Assuming that you've locked in the maintenance over the five years to 20 percent of the purchase price, that set of options is worth $2.85 + $4.25 + $5.35 + $6.35 = $18.80. Five years is not an unreasonable horizon for enterprise software.

But wait, there's more.

Another option included in the license price is the option to upgrade to future versions at some price that will be less than the regular price. Right? That's clearly an option. The same informal poll of enterprise software users asked what they would pay for software when they didn't have the option to upgrade to the next release. The strike price is less standard than regular maintenance. (If you think about it, new versions perform "maintenance" by adding features as opposed to fixing bugs.) Now we're buying an option to upgrade in five years as part of this license.

The underlying price--the price you'd have to pay if you didn't have an option--we'll leave at $100. The next version will be priced the same as this one. Because you're upgrading, you have an option with a strike price of, let's say, $50. That is, you'll be able to upgrade to the new version for only $50. A five-year option for a $100 underlying price with a strike price of $50 and a volatility of 30 percent (with a 5 percent risk-free rate) is about $62.50.

Of course, most software offers new releases more frequently than once every five years--but enterprises don't like to upgrade very often and usually plan on skipping every other release in order to avoid upgrading too often. Then it would be two options. Much like adding additional planetary bodies to a problem in gravitational dynamics, the complexity mounts rapidly. I'm trying to keep it simple. (I suggest follow-up research problems for interested students.)

At this point, the astute reader will have noticed that the sum of the value of the option for the upgrades plus the options for the maintenance is $18.80 + $62.50 = $81.30. That is to say, our $100 software license consists of $18.70 for the value of the actual software and $81.30 for options on future maintenance and enhancements.

This seems to correlate with the reaction I mentioned earlier that software without the option to get maintenance or upgrades is worth significantly less than the software with those options.

In fact, if we suggest that the maintenance is actually worth $25 instead of $20--but the option strike price of 20 is embedded in the so-called license--then the price of the maintenance options goes to $34.15, and the software itself turns out to be worth about $3.35.

The financially sophisticated may take a few exceptions. My interest rate is wrong. The volatility assumption is wrong. There isn't really an option contract, because those prices aren't guaranteed. Not only that, but they aren't really options, they're warrants. The distinction is that options are bought and sold by third parties--there can be a market in options without the participation of the owner of the underlying asset--whereas a warrant is sold only by the owner of the underlying asset. Pricing on warrants, therefore, differs from pricing on options.

Fair enough on all of these objections, but the point I'm trying to make is this. Those who have suggested that open source and free software is somehow not capitalistic, destroying the value of software and other such assertions, have missed this alternative explanation. It is just as likely that the free and open source software folk have stumbled across the financial engineering insight that a significant portion of the value of software is the embedded "derivatives"--options or warrants--on future maintenance and enhancement. Whether one believes that software has intrinsic value is related mostly to one's view on the correct value to use for volatility in calculating the option value. Larger values of volatility mean the software itself is worth less. Smaller values of volatility reduce the option price, and the software is intrinsically worth more.

Therefore, the major difference in worldview between open source advocates and proprietary software license advocates is explainable as a differing opinion on the correct value of the volatility of maintenance and upgrade pricing. People who believe that the pricing on maintenance is stable and unlikely to change see greater intrinsic value in the software. People who fear that the pricing is subject to large fluctuations see no intrinsic value in the up-front license; stripped of the options, the license value approaches $0.

For the open source movement, perhaps a better way to position the change that OSS is making is this: we're converting warrants on future maintenance and enhancements into options, which means that instead of having a sole supplier (warrants), we have created a third-party market (options) of these derivatives.

How capitalistic is that?

Robert Lefkowitz has spent 30 years weaving software for the airline, nuclear power, financial services, and telecommunications industries.

source:http://www.onlamp.com/pub/a/onlamp/2005/07/21/software_pricing.html

# posted by dark master : 7/24/2005 02:49:00 PM  0 comments