How Do I Become a Print Manager?

The book analyzes the growing economic base of the open source phenomenon. Nine open-source development models are given, two of which are not profitable and seven are profitable. Developed a qualitative theory of when closed code is economically reasonable. Examining several novel open source development methodologies for profitability invented when the market was invented, they finally reached a conclusion and tried to make some predictions for the future.

Magic Boiler

In the "free" transformation, it is not the programmers who are losing, but the investors who have bet on closed source strategies without seeing the situation clearly.

We can expect that in the future, with the strong competitiveness brought by free software, the final fate of a certain software will either go to extinction or become part of an open component system. Although this is indeed bad news for software companies that intend to make profits from closed software forever, the software industry as a whole is still an industry. At that time, new high-level application software will continue to open and privatize intelligence. Resource monopoly on a certain software will only have a limited life cycle and will eventually be transformed into free software.

The "Magic Boiler" (The Magic Cauldron) is an important book published in the summer of 1999 by Eric Raymond, an international free software celebrity. Xiaobo once likened Richard Stallman to the Pope of the Free Software Kingdom, Linus the King in Power, and Raymond to a dedicated Prime Minister. This metaphor is very interesting and quite visual. Eric Raymond is always working hard to promote the development of free software. His articles such as "A Brief History of Hacker Culture", "How to Become a Hacker", "Cathedral and Bazaar", "Explore Wisdom", etc. are always It has shocking power, so when iasc introduced me to this new work for the first time, I felt that this article should be translated into Chinese so that more domestic computer enthusiasts can appreciate its power. After I glanced at the full text, my determination to translate was even greater, but in the face of such a great work with so much content, so much connotation, and very extensive citations, I flinched a bit. Fortunately, I got the enthusiastic encouragement and cooperation from friends such as iasc, merlin, and also received the support and help of netizens such as wclee, liyuhang, sto, ly_hust, kiwi, lilly, wl_wan, etc., so that this Chinese translation can be released to the market and pleased At the same time, I also express my most sincere thanks to all the friends who participated in the translation.

This article analyzes the growing economic base of the open source phenomenon. First it overturned some popular myths about program development funding and software price structure. A game theory analysis on the stability of open source collaboration is given. Nine open-source development models are given, two of which are not profitable and seven are profitable. A qualitative theory was then developed to show when closed code is economically reasonable. Then it examines several novel open source development methodologies that are invented in the current market, including the introduction of sponsorship systems and task markets. Finally, I came to a conclusion and tried to make some predictions for the future.

Eric Raymond (June 1999)

[AKA] rover HansB iasc

table of Contents

============================

Almost magic

2. Beyond the talent of the master

3. Manufacturing illusion

4. The "information needs to be free" myth

5. Refuting Public Tragedy

6. Reasons for closed source

7. Use value fundraising model

7.1 The Apache Case: Cost Sharing

7.2 Cisco Case: Risk Dispersion

8. Why is there a problem with sales value

9. Indirect sales value model

9.1 Failure Leader / Market Positioner

9.2 Icing Strategy

9.3 Deliver recipes and open restaurants

9.4 Derivatives

9.5 Charge now, free in the future

9.6 Software is free and sold as standard

9.7 Free Software, Selling Content

10. When to open and when to close

10.1 What makes a profit?

10.2 How do they interact with each other?

10.3 Doom: A Case Study

10.4 Know when to let go

11. Open source business operations

12. Successful replication

13. Open R & D and secondary development

14. From here and there

15. Conclusion: After Free Software Transformation

16. References and acknowledgements

17.Appendix: Why Closed Drivers Lose Seller Money

18. Revision history of this document

In Welsh mythology, the goddess Ceridwen has a huge pot, and when the goddess chants a spell that only she knows, the pot becomes a wonderful food. In modern science, Buckminster Fuller put forward a concept of "transient", thinking that under the situation that more and more investment in physical resources was replaced by information content, technology would become more and more effective and cheaper. Arthur C. Clarke points out that "any advanced technique is the same as magic", thus linking the two. For many people, the success of the open source community looks like incredible magic. High-quality software becomes free. In the real world full of competition and scarce resources, this does not seem to continue, but it works well. Where is the point? Is Ceridwen's cauldron just a little trick? If not, how does "temporary" work in this case-what spell did the goddess chant?

The experience of an open source culture is sure to confuse many people who have studied software development. The article "Cathedrals and Bazaars" describes how decentralized collaborative software development has effectively overturned Brooks's law, resulting in a development approach that enables an independent project to have unprecedented reliability and quality. The article "Expanding the Wisdom Field" reveals the social dynamics in the market model development style, which should be understood in terms of anthropologists' "gift culture" rather than the conventional exchange economic terms. Compete in making contributions. In this article, we will begin to overturn some popular myths about the economics of software production; then we will analyze the fields of economics, game theory, and business models for the two articles, "Cathedral and Bazaar" and "Explore Wisdom." A new conceptual tool to understand why open source developers' gift culture can continue in the exchange economy.

Without leaving the topic, following the clue analysis above, we need to abandon (at least temporarily ignore) the analysis at the "gift to culture" level. The existence of the gifted culture in "Explore the Wisdom Field" is based on the extremely rich material information needed for survival, so that the social exchange is no longer important; this analysis is very convincing in the purely spiritual world, though , But for the comprehensive economic environment where most open source developers actually live, this explanation seems a bit weak. For many people, social exchange is still the driving force behind their hard work, but it has gradually lost its appeal. Sufficient reasons must be found for their actions in resource-poor economics in order for these actions to gain a foothold in a materially rich gifted culture.

Therefore, we will now consider (from the entire field of resource scarcity economics) the collaboration and exchange model for maintaining open source development. In the process of analysis, through in-depth analysis and enumeration of examples, we also answered the very practical question: "How can I make money through open source?". However, this question is based on a general software development economic model that runs counter to the nature of software development. First, we need to show many of the misunderstandings behind this question.

(Before starting the analysis, there is one last thing to explain: the discussion and promotion of the open source development model in this article cannot be understood as a complete negation of the closed source model, nor does it oppose the existing software intellectual property system, more Not a selfless call for "sharing." Although some in the development source code development community are still keen on these discussions, since the publication of the "Cathedral and Bazaar", experience has clearly shown that these arguments are not necessary. It is important that The open source development model and economic benefits can produce good products with better quality, higher reliability, lower cost, and more options.)

What we need to note is that computer programs, like other types of tools and capital goods, have two economic values: use value and sales value.

The use value of a program is its economic value as a tool; the sales value is its value as a commodity. (In economics, the sales value is the final value of the product, and the use value is the intermediate value of the product)

When most people talk about the software industry, they always analyze according to the "factory model" economy with the following characteristics:

1. The labor of most developers is paid for by the value of sales

2.The software's sales value is proportional to the development cost (e.g. resource expenditure required for functional replication) and use value.

In other words, people have a strong inertia to assume that software has the characteristics of standard industrial products. But both assumptions are wrong.

First of all, writing code for sale is just the tip of the iceberg of the programming industry. In the early days of the microcomputer world, it was generally believed that 90% of the code in the world was written inside banks and insurance companies. Although this is no longer the case-other industries are now also More and more software development has been done, and the proportion of the financial industry has decreased-but in the short term we will still see that about 95% of the code is written in-house.

These codes include most of the MIS, financial and database software customized for medium or large companies. They include professional technical codes such as device drivers (almost no one makes money by selling device drivers, which we will discuss later); Includes a variety of embedded code for growing CNC machines-from machine tools and jetliners, cars, microwave ovens and even toasters.

Most of this internal code is integrated with its environment, making it difficult to copy and reuse (regardless of whether the environment is a commercial office program suite or a combine's fueling system). So once the environment changes, much work needs to be done to synchronize the software with it.

This kind of work is called "maintenance". Any software engineer or system analyst will tell you that this is the source of most of the programmer's salary (more than 75%). Therefore, most program employees spend more time writing and maintaining than they can On the internal code sold (of course most programmers make a living from it)-readers may be happy to check the programming job list in the "recruitment information" section of the newspaper.

I strongly hope that readers can try to browse the recruitment information of local newspapers, look at programming, data processing, and software engineering projects that include software development work, etc. You will be well received by classifying these jobs according to whether they are used or sold. Inspiration.

Obviously, even if the maximum scope is defined for "sales", at least 19 of the 20 people are funded by value in use (as the intermediate value of the product). This is why we believe that the software industry is driven by sales value only 5% Note that the analysis in other parts of this article does not rely entirely on this number; even if this number reaches 15% or even 20%, the economic inference results are still intact.

(When I speak at technical seminars, I often start by discussing two issues: how much the audience pays to write the software, and how much salary depends on the value of the software's sales. The first question is answered by many people. (The second question is very few, and the large and large audience is very surprised at this question.)

Secondly, after investigating actual customer behavior, the theory of software sales value and its development and upgrade costs can easily be overturned. Products related to development and upgrade costs (previously discounted) account for a large proportion-food, cars, Machine tools even have many intangible products-for example, the right to reproduce music, maps or database materials. This product can maintain or even increase its sales value after the producer's failure.

In sharp contrast to the above, when a software product producer goes out of business (or if product development is terminated), few customers are willing to spend money for it, regardless of its theoretical use value or the development cost of the same functional product. How high. (To test this claim, go to the discount counter at a software store near you :-))

When the producer fails, the retailer's behavior is very enlightening. They know something that the producer does not know. They know that the price that customers are willing to spend is largely determined by the services that the seller can provide in the future. (Here ('Service' is broadly understood as perfecting, upgrading and follow-up products).

In other words, software is mainly a stable service industry, and there is no reason to think that it is a manufacturing industry.

In addition, it is also useful to check why we have these habitual thinking. They may come from sales products that are strongly promoted by software producers. These are a small part of the software industry and the only part of the promotion. The products of the heavy advertising are short-lived short-term products, just like games, and they rarely need to provide follow-up services (except as stipulated in the contract)

In addition, it is worth noting that the price system advocated by the manufacturing illusion will actually cross the bottom line to keep the development budget from collapsing. Since (as generally believed) more than 75% of the typical software product cycle cost is spent on maintenance, debugging and expansion , Then the usual pricing strategy that only uses high prices and very low related service fees will only lead to poor services in all aspects.

The user's loss is that even if the software is a service industry, the factory model prompts producers to reduce the quality of service. If the producer makes money by selling bits, a lot of effort is to make bits and sell them out; help the service part because it is not profit The center will become a little bit of effort and resources, in order to avoid irritating users to set up garbage stations.

On the other hand, the use of this factory model by most producers will lead to long-term failure. Funding fixed-price products that meet unlimited after-sales service and technical support needs is only in those markets that have expanded rapidly enough-their past Sales and future revenues can meet the costs of support and life cycle-to survive. Once the market matures and sales decline, and sustain their livelihoods, most producers have no choice but to cut spending on individual products.

Regardless of whether it is direct (discontinued product) or indirect (poorly supported), customers will be pushed to competitors (because these actions undermine the expectations attached to the service product). In the short term, it is possible to New products avoid this trap. In the long run, the only possibility to avoid the trap is to have an effective market monopoly on the industry. In the end, there is only one survival.

In fact, we have repeatedly seen that this unsupported model kills some strong competitors in the market environment. (This model is especially profound for those who have survived the history of computer development, including personal operating systems, (Word processing, general financial procedures or business software). This incorrect motivation comes from the winner-take-all situation caused by the factory model, and in the end even if you are the winner's customer, you will suffer.

If it is not a factory model, what is it? In order to effectively control the real cost system of the software life cycle (also "effective" in the sense of economics and informal settings), we need a service contract, contract, and The price system based on continuous transactions between buyers and sellers. Therefore, under free market conditions for the purpose of efficiency, we can look at the price system that most mature software industries eventually follow.

Why is the status of open source software growing, not only technology, but also the economic challenge to the mainstream order? The above content gives us some inspiration. The "free" of software development will push us to a world dominated by services. Exposing how fragile the way has been to rely on selling closed source products.

The concept of "free" is easily misunderstood as something else. Reducing product costs will lead to an increase, rather than a decrease, in the overall base investment that underpins the software industry. Only when the price of a car goes down will the demand for cars rise-this is why in the open source world, the other 5% of programmers who are paid based on sales value are uncomfortable. There is a loss in the change of free It's not the programmers but the investors who are betting on closed source strategies without seeing the situation clearly.

In response to the illusion of the factory model, people thinking about the open source economy are often confused by another myth. That is "information should be free". This is often explained by the marginal cost of copying digital information products is almost zero. This explanation It implies that its price seems to be zero.

In fact, you only need to think about the value of information such as treasure maps, Swiss bank account passwords, or computer service confirmation passwords, etc., it is easy to see through this myth. Even if these confirmation information can be copied without any cost, but by its Confirmed objects cannot be copied; that is, non-zero marginal costs are inherited by those confirmed information.

The main purpose of mentioning this myth is to state that it has nothing to do with the discussion of the economic value of open source; as we will see later, even if the software is assumed to conform to the (non-zero) value structure of manufacturing products, this is still the case. So we don't need to dig into whether the software should be free of charge.

Question the mainstream model and see if we can build another model-a strong economic explanation of what is supporting open source collaboration.

This question needs to be examined from two different aspects. One is that we need to explain the individual behavior of those who contribute to open source. On the other, we need to understand the economy that supports open source projects like Linux and Apache. power.

Hardin's famous parable tells us: Imagine a rural farmer who owns a common green space. They graze livestock there. But grazing degrades commonality, tears the turf, leaves mud, and is difficult to recover. If the right to allocate grazing is not reached An agreement (or agreement) to prevent overgrazing; all herders will also favor increasing the number of livestock as quickly as possible in order to squeeze the maximum profit before public green spaces become mire.

Most people use an intuitive model of cooperation like this. This is not really an open source-they are free knights (in short supply) and not (overused) excess public goods-a correct judgment of economic issues. However, I heard similar opinions behind most of the underconsidered objections.

There are only three consequences of tragic prophecy for public ownership: one is a quagmire; the other is for the benefit of the villagers to use a distribution agreement (communist solution) forcibly; the third is that the public is broken and the villagers Build barriers and protect a small piece of grass (private solution).

When people instinctively apply this model to open source cooperation, it is expected to have a very unstable short half-life. Because there is no obvious way to force programmers working on the Internet to implement a work time allocation strategy, this kind of The pattern asserts that the public will break, and as a result, a variety of closed code software and the workload of feedback to the public will rapidly decrease.

In fact, experience clearly shows the opposite trend. The breadth and depth of open source development (statistics announced daily by Matalab) is steadily increasing. Obviously, these all lead to the "public tragedy" model cannot Describe developments.

Part of the answer is based on the fact that software use does not reduce its value. In fact, for open source software, when users are grasped by its modifications and features (code patches), the widespread use of software will still Increase its value. Public tragedies are upended, the more grazing the grass grows.

This road is good no matter how far. However, this is only a postmortem explanation after the hacker wrote the patch and published the patch. The other half of the answer we need is why JRH originally wrote this patch, and It's not working for closed source programs with sales returns. Making economic explanations. What business model has created an environment for open source development to flourish?

Before categorizing open source business models, we should first consider the cost of closure in general. When we close the source, what exactly are we protecting?

Let's say you hire someone to write and organize a settlement software for your business (let's say), compared with open source, closed source will not help solve the problem at all. If you want to close the source, The only reasonable reason is that you want to sell this software to others, or prevent your competitors from using it.

The obvious reason is that you are protecting sales value, but this is meaningless for 95% of software for internal use. So is there any other benefit to being closed?

The second reason (maintaining a competitive advantage) has yet to be tested. If you say that the settlement software is open source, it has become popular, and it has been improved from the community. Now, your competitors have also started using it, and he has not Spending on development costs benefits you and affects your business. Is this a reason to oppose open source?

Maybe-or may not. The real question is whether you get more from the decentralized development burden than the competitive losses that come from those who do not work. Many people tend to justify such transactions pale. : (a) Avoid talking about the functional improvements obtained from the additional development assistance. (b) Do not think that the development costs have been reduced, but assume that you will bear these development costs anyway, so treat them as The price of open source (if you choose this way) is wrong.

There are many other reasons why closed source is ridiculous. For example, you may mistakenly think that closed source can make your commercial system more secure and not easy to be cracked or broken. If so, I suggest you find one Cryptologists to diagnose your system. Real suspicions know that they cannot trust the security of closed source programs, because this is what they have learned from the painful lessons. Security is an aspect of reliability; Only those algorithms and code implementations that have been thoroughly checked can be considered safe.

One of the basic facts that we noticed as the difference between use value and sales value is that only the sales value itself is threatened by the transition from closed source to open source; use value is not.

If use value, not exchange value, is indeed the fundamental driving force for software development; and the development of open source code is indeed more influential and efficient than the original code, then we should look forward to finding an environment In this environment, the use value alone has been able to completely promote the development of open source code.

In fact, such several environmental models are not difficult to find. In such a model, the survival of a full-time developer of open source code can be realized by use value (of the open source code).

7.1 Aapache's case: (value sharing)

Suppose you are working for a commercial company with an efficient and reliable web server. Maybe this server is used to serve e-commerce, maybe as a highly visible media output device that sells advertisements, or maybe just to build a portal site. You need to be online 7 hours a day, you need speed, and you have to be normative.

So how do you do it? Here are some basic strategies for your reference:

Buy a private web server. In this way, you are risking to believe that the seller's promotion is consistent with your needs, and you are risking to believe that the seller's technical competitiveness can provide perfect protection. Even if these two aspects are assumed to be guaranteed, the web server itself will suffer from a lack of standardized services. You can only maintain your server through several tools provided by the seller. This way of buying a private server is not a very popular method!

Make it yourself! Making a web server of your own is still a negligible method of adjustment; the web server is not too complicated, of course, it is simpler than a browser. A purpose-built web server can be functionally specific but easy to use. In this way, you can get all the features you need and your own specifications, although you have to pay a lot in the process of upgrading. Maybe after you leave or retire, your company will find this server has one or other problems.

Join the Apache team! The Apache server was written by a team that communicates through the Internet-the team members are system administrators, and they believe that it is wiser to pool their capabilities to write and improve a single set of code instead of going Spend time each writing completely irrelevant code. As a result, they are able to take advantage of both do it yourself and large-scale, large-scale test code.

The advantages of choosing the Apache team are clear. How obvious it is, you can judge it based on Netcraft's weekly review. Netcraft said that the Apache server has been steadily gaining market share from other private servers since its inception. In June 1999, various versions of Apache accounted for 61% of the market share. There were no legal owners, no organization, and no contractually controlled organizational form.

All in all, Apache's story provides a pattern: software users have discovered this pattern by supporting the Open Source Project, and they have found that doing so can bring them better and better software at the least cost, better than others Any method must be effective.

7.2 Cisco Cases: Risk Sharing

Some years ago, two Cisco (network product manufacturer) programmers were assigned to write the code of a distributed printing system for Cisco's cooperative network applications. The project was challenging. This system should allow any user to print on any printer on the network (and the user and the printer may be just next door or thousands of kilometers apart). When the printer is out of paper or other emergency systems, it must be able to direct tasks Another printer nearby. The system also needs to be able to report this burst time to the printer administrator.

The two of them made some very good modifications to the printing software on Unix, and added some packages to the original language to complete the job, but then the problem came.

The problem is that both programmers are reluctant to stay with Cisco forever. As a result, both programmers will leave, and the software will be "rotten" without maintenance (that is, it cannot meet the changing requirements in actual applications and loses its application). No one wants to see this happen on his own or at work. The two programmers also think that they have done what Cisco asked them to do, and other issues are beyond their scope of work.

So they went to their manager and asked to open the original code of the printing software. They think that Cisco will not only lose nothing but gain more. By collaborating to encourage the development of organizations of users and software development partners, Cisco can make up for the loss caused by the departure of software originals.

Cisco's story leads to another model: the open source code makes the risk of developing a software shared by many collaborators and the investment cost is small. All groups have found that the openness of the original code and the existence of a community where members are independent but collaborate with each other will provide a risk-free development environment, and this environment is of commercial value-it can make money to support itself!

Open source makes it very difficult to directly obtain software sales profits. The difficulties do not come from the technical side, because the source code is as easy to copy as the executable code, and the constraints of copyright law and license law make it harder to obtain sales profits through open source software than closed source software.

The real difficulty comes from maintaining the license itself for open source development. For three mutually-motivated reasons, most open source licenses prohibit restrictions on users' rights to use, distribute, and modify software, thereby avoiding the use of open source software for direct profits. In order to better understand these reasons, we need to understand the social background involved in these licenses-the hacking culture

The reason has nothing to do with hostility to the market, although such misunderstandings have spread widely outside the hacker community. It is not excluded that a small number of hackers have always been hostile to business motives, but most of them are still willing to cooperate with some Linux integrators (such as RED HAT, SUSE, Caldera) for profit. This also shows that as long as they meet their wishes, most hackers will be happy to cooperate with the merchant. From this perspective, the real reason why hackers are hostile to licenses for direct profit is very subtle and interesting.

One reason is the principle of reciprocity. Most open source developers allow others to use their achievements for profit, and many open source developers also stipulate that one party (sometimes except source code developers) is not allowed to make profits out of privileged status. As long as the hackers intend to make a profit from the software or patches they develop, they are generally willing to cooperate with him to make a profit.

The second reason is the unexpected consequences. Hackers have found that restricting and charging for the commercial use and sale of software in licenses (a common practice for selling profits) makes relationships indifferent. One special case is the so-called "pirated CD", which should have been encouraged, but is now considered illegal and unethical. In general, restricting users' rights to use, sell, modify, and distribute software (as well as other complex rights in copyright agreements) can lead people to follow the rules and worry about breaking the law all the time. The number of software packages has increased. This is undoubtedly very bad, so simplifying the license and lifting the restrictions in the license have become the general trend.

The third reason, and the most critical one, is code sharing. This culture of gifting is vividly described in the article "Explore the Wisdom." Certain regulations in the licensing system used to protect intellectual property rights or restrict direct access to sales profits prevent people from legally sharing code (such as Sun s Jini & Java "Community Resources" license). However, code sharing is considered the last life-saving "straw" (the problem is explained in large sections in the article "Explore the Wisdom"), when software maintainers cannot afford or give up the maintenance of the code (for example, A very closed license), code sharing is critical.

The hacker community has compromised on the principle of reciprocity, so they can tolerate licenses that give source creators privileges like Netscape's NPL (the NPL explicitly prohibits non-public source products from using open source Mozilla code). For the second reason, there are fewer compromises. Concessions to the third reason are rarely made (this is why Sun's JAVA and Jini Community License plan has been widely opposed by hackers).

The above reasons explain the terms in the definition of open source. These clauses express the ideas of the hacker community from the subtle characteristics of some typical free software copyright agreements (such as the GPL agreement, BSD agreement, MIT agreement, and Artistic agreement), and they (though not intentionally, but objectively) make direct profits Extremely difficult.

However, there are ways to explore software service-related markets and gain indirect sales value. There are five known and two models being explored (more new development models may be developed in the future).

After examining several business models that support open source software development, we can discuss the general issues of when open source code and when closed source code makes economic sense. First, we must figure out how profitable each strategy is.

In the open source community, it is common to organize its own business activities in a way that tends to increase the effectiveness of open source production. Especially in the world of LINUX, there is a fact of great economic significance, that is, there are many competing publishers, and they form a separate and independent level from the development community.

Developers write the original code and make it downloadable on the Internet. Each publisher selects some of these downloadable source codes, synthesizes them, packages them, registers them, and finally buys them for customers. Users can choose a publisher's product or supplement their own installed distribution by downloading the original code directly from the developer's website.

The role of this layer formed by the publisher is to create an internal market that is very easy to change and can continuously improve the product. Developers are competing with each other on the quality of their software in order to attract the attention of publishers and customers. In order to make more money from users, publishers compete with each other on their strategy of choosing the original code and the added value they bring to the software.

The common tragedy may not lie in their adaptability to the development of open source business models that exist today, but this does not mean that there is no reason to doubt whether the current situation in the open source community can continue. Will the main players betray common cooperation as the risk increases?

This issue can be raised at several different levels. Our opposite story to "successful public" is based on the assertion that the value of an individual's contribution to open source code is difficult to measure quantitatively. But this assertion does not have much influence on companies like Linux publishers who already have a portion of the revenue associated with open source code. Moreover, their daily contribution value has been quantified. But is this cooperative role solid now?

Research on this issue will lead us to interesting thinking on some issues, such as the economic status of open source software in the real world today, and what will be the model of the true software service industry in the future software industry.

Perhaps for now, a software license system that expresses the LINUX community guidelines in a form that is combined with the law is actively preventing RED HAT from monopolizing their open source products. The only thing they can sell is a brand, service, and technical support relationship with users who voluntarily pay them. This will not make the overwhelming possibility of monopoly situation much.

Another reason why investors invest in the open source world is to change him. Developers are beginning to feel that they can get paid for what they want to do, instead of using their formal work income to maintain their hobby of the open source movement. Companies like Red Hat, O'Reilly Associates, and VA Linux System are exploring how much investment it takes to establish semi-independent R & D institutions by hiring and maintaining stable and capable open source programmers.

This approach is only economically viable if the company's revenue from rapid market expansion is sufficient to cover that type of research laboratory. The reason why O'Reilly can afford the main authors of Perl and Apache to complete their work is because after hard work, the company can sell books related to Perl and Apache; the reason why VA Linux System can provide the laboratory with sufficient funding is With the prosperity of Linux, they can sell more workstations and servers; Red Hat can afford his advanced R & D laboratory also because the laboratory can continuously increase the value of the company's Linux products and attract more users.

What will the entire software industry look like after the transition to free software is complete?

In order to answer this question, it is necessary to classify software according to the degree of service that the software needs to provide to users. Services reflect the openness of the software. This division is closely related to the degree of marketization of services provided by the software. The essence of this formulation is exactly similar to the three terms we usually say: applications (basically no commercialized services, no or lack of open technical standards), components (commercialized services, strong standardization), middleware (Requires some commercialized services, technical standards but imperfections). Current (1999) typical examples of the above three types of software are word processing software (applications), TCP / IP protocol packages (components), and database engines (middleware).

Finally, we need to see that this change from closed to open is still driven by users of software products in order to continue to develop. More and more high-quality software will be created and used for a long time, instead of being hidden in the back room by some people and not being developed. This miracle is not adequately compared with Ceridwen's magic pot, because the food produced by the magic pot will gradually decay if not eaten, and the software in the free software world will be an inexhaustible treasure. You have the most free freedom in free software. Whether you intend to provide business services or contribute to him, the world of free software will provide everyone with an inexhaustible wealth of wealth that is continuously accumulated.

[DL] De Marco and Lister, Peopleware, Productive Projects and Teams (New York; Dorset House, 1987; ISBN 0-932633-05-6)

[SH] A great work by Shawn Hargreaves on how to combine open source with game production Playing the Open Source Game

In the course of completing this article, through several intense discussions with David D. Friendman, I have further refined the chapter of "Climbing Commons" which introduces how to strengthen the cooperation of the open source community. Thanks to Marshall van Alstyne for pointing me to the exact meaning of "hot information product", I owe him a favor. Ray Ontko of the Indiana group gave me a lot of useful criticism. There are also a lot of enthusiastic listeners who gave me a lot of help when I gave a speech in June this year. If you are one of the audience, you will understand who I mean.

After I published this article, I also received a lot of material about the development model of free software via email, which have continuously enriched the content of this article. Lloyd Wood pointed out the importance of "future benefit" free software development model; Doug Dante reminded me of the business model of "free future"; Lionel Oliviera Gresse helped me give a better name to a business operation model; Turnbull gave me a head start for ignoring the Cavaliers phenomenon.

Why hardware vendors that close the driver's source code will waste investors' money. Peripheral device developers, such as manufacturers of network cards, hard drives, or graphics cards, have traditionally closed the source code of the driver. However, this phenomenon has now changed. For example, Adaptec and Cyclades have become accustomed to making the driver source code and corresponding documentation of their various boards public. However, there are still many difficulties to make open source a common practice. In this appendix we intend to clarify some misconceptions that still maintain a closed source code system in the business world.

Assuming you are a hardware manufacturer, you may worry that opening up the driver code will reveal many important secrets of how your hardware works, so that your competitors can analyze your source code to cause you an injustice Competitive environment. This idea may hold up in an era when the product will be updated in three or five years; but even if the source code is open today, your competitors will have to spend a large part of the entire product update cycle Come to think about the code that you have made public, because now the product update cycle is greatly shortened, and your competitors will not have enough time to think and innovate their own products. So the moment they went to study your open source code actually got into your trap.

Sticking to the closed line is a dead end, your secrets will inevitably be gradually revealed, you will not get the help of free programmers, and no stupid competitors will spend time imitating your design. What's more important is that if you adopt open thinking early, you could have a wider development space, but you missed it. Because your equipment is too conservative, lacks information and stands still, and cannot recognize your own mistakes, the huge market formed by most network administrators and more than 17% of commercial data centers on the Internet will take your hardware equipment They removed the purchase list and turned their attention to other open hardware vendors.

What you see now is version 1.14 of this document

In the list below, some minor revisions and print editions are no longer listed.

May 20, 1999, Version 1.1-Draft

June 18, 1999, version 1.2-the first version for private communication

June 24, 1999, version 1.5-the first version released to the public

June 24, 1999, version 1.6-Minor changes were made to give the definition of 'hacker'.

June 24, 1999, version 1.7-some standards clarified

June 24, 1999, version 1.9-Added discussion of "future benefits", "free future" development models, and chapters on the cost of closure

June 24, 1999, version 1.10-better title for Blade mode

June 25, 1999, version 1.13-Corrected 13% of Netscape's revenue issues, added analysis of Free Cavaliers, and corrected list of closed network protocols.

June 25, 1999, version 1.14-Added e-smith example

July 9, 1999, version 1.15-Updated the content of the hardware driver appendix and gave a better explanation of "hot items" with the help of Rich Morin.

Eric Steven Raymond is the author of The Cathedral and the Market, the maintainer of the New Hacker's Dictionary, and a famous hacker. As the main editor and maintainer of the New Hacker's Dictionary, Eric Raymond has long been considered a historian and anthropologist of the hacker culture. But after 1997, Eric Raymond was widely recognized as one of the main leaders of the open source movement and the most well-known (and most controversial) hacker.

Raymond

In 1957, Raymond was born in Boston, Massachusetts, USA. It is exactly where MIT, the birthplace of hacker culture, is, and Stallman's base for free software. But Raymond has been walking around the world with his parents since he was a child. He had forgotten two languages before he was 13 years old. In 1971, he returned to Pennsylvania, USA, and began to contact the hacker culture in 1976. In 1982, he completed the first open source software project. Raymond is not just an inexperienced pen. He is one of the main creators of the INTERCAL programming language and once contributed to the EMACS editor. Raymond is also the author of the famous Fetchmail program ^[1] .

In 1990, he edited the New Hacker's Dictionary. From then on, he became fascinated with hacker culture and became a historian of hacker tribe and a scholar of hacker culture. In 1996, he wrote "A Brief History of Hacker Road". He began to position himself as an anthropologist: "The work of anthropologists is to study human behavior and society as a whole, to study the formation of human culture, how culture works, how culture changes over time, and how humans adapt to different Cultural environment, etc. I think about the culture of computer hackers the most, and focus more on the analysis from the perspective of society than on their superb technology and procedures. "

He abbreviated his name and ESR as the hacker code name. Raymond manages more than 30 open source software and more than 10 major FAQs. He is also an important writer and weblogger. He is one of the main creators of the INTERCAL programming language and has also contributed to the development of the EMACS editor. Raymond is also the author of the Fetchmail program.

Raymond's famous saying, "Given enough eyeballs, all bugs are shallow", has a great influence on the open source movement, which is also known as Linus's law.