Project management and engineering are issues that have been largely ignored in free source code development. Recently, Monty R. Manley published this issue in LinuxProgramming.com, but I reserved some of his opinions.
Introduction
Project management and engineering are ignored major issues in free source code development. Monty R. Manley pointed out this issue in an article entitled "Open Source Road" article. He recommends adopting more traditional software development modes in free source (with my understanding, referring to free software and open source) projects. I absolutely agree that better engineering practice is needed. However, I think we need to do it, understand the operation of free source, especially in its success, and sending engineering practices in line with their culture.
Manley's article is a deep province and stimulates that I have further considered some problems that have been considered. I have led a free source code (GIMP-print, I have faced a lot of such problems. In my career, I am often both developers and issuing engineers, and I have also exercised some observation capabilities in this regard.
In this article, I will explore some of the issues raised by Manley, analyzing how these methods are applied in the free source community, and some suggestions, or at least point out some questions that should be paid attention to in future work.
Waterfall model and traditional methodology
Since over the years, the methodology used in software development is a waterfall model: first is a careful demand analysis, the development group has steps to develop a function (structure) description, followed by the summary design, detailed design, and then start coding. After the encoding is completed, the software can then be released. This looks very logical; only after understanding. Software in this strict manner, the engineer is clearly clear what you should do. Many people put forward a variety of methodology based on this model; there are also quite a few commercial tools to make these steps more mechanized and not easily errors.
According to I understand Manley's point of view, a weak point developed by free source code is (demand and design analysis) in the (waterfall model) to be largely ignored. I don't agree with this point of view, the reasons are as follows:
There is a serious defect in the waterfall model. Free source code has indeed a demand analysis, just use different methods.
First discuss the deficiencies of the waterfall model itself. MANLEY asked:
If you don't know what you want to do, how can you write a program?
Asked well. Don't know what to do? None normal people will consider making a bridge without knowing what to connect, how large traffic flows, and how the geological conditions and some similar issues. Is the software differences?
Usually not. Software team of the space shuttle project is famous, because they don't have to work more than 80 hours a week to deliver bug-free software in time. Programmers develop embedded code for medical monitor must release products in the class under the same strict conditions. In these cases, discipline strict teams have indeed followed such models: obtain demand, repeated iterative design and inspection, and then start coding. In many cases, the encoding is just a large-scale mechanical process, and the bug in the early construction is quite concerned, as this indicates that there is an error in the previous period. But is this model really efficient? Is it more appropriate to free source software or more commercial software? I believe that it is not appropriate to be appropriate.
The two examples I have just said are harsh applications, and software is just part of the big project. This is just to sacrifice the slow and careful process of the innovation to reliability. For example, this medical monitor, programmer emphasizes reliability and correctness rather than a trendy image, I don't know if I have the relationship with such a project. Most of most software that most people directly reach is not so harsh; they just have to complete the task.
This doesn't mean that I agree with this compromise, such as Microsoft; they are too extreme, even at the bottom of the operating system, so that the foundation is unstable. However, the key is because this fundamental is not perfect, most computer users have gain more functions; perfect and excellent are opposite, the difficulty is what is "better". For example, simple, in many cases do not require a perfect structure. On the other hand, the shortage of work will leave a lot of hidden dangers. The more software relying on a package, the more important the reliability of this package. Disadvantages of traditional demand analysis
On the other hand, the user usually doesn't know what the program is going. Experts from spaceplane projects know what they need, and they have experienced how to express it. For example, users of word processing software know that they need to edit and typography, but only on ordinary levels. It is almost impossible to get a comprehensive demand before you start working. If the editor does not automatically retract, the user can say "Oh, I really don't like manual indentation"; but the user is hard to think of this. Users who have not been properly trained will not know how to express those (her) do not understand the needs.
This is the so-called GIGO (misfunction error) theorem: If the initial demand is useless, any function description according to these needs is also useless. The final product produced according to the waterfall model will be a white elephant.
Sometimes I observed this situation. In order to abide by the rules, the programmer did write a functional description and design, but after writing and debugging the code with a certain function. Sometimes everyone will be regarded as this situation; some people complain that doing things or cause other troubles; sometimes this causes managers do not know the development progress. Sometimes - in my opinion - is a reasonable requirement and reasonable response.
The requirements for demand, structures, and design documents are quite rational, even if it is not so reasonable, even if the design document indicates the next stage programmer's task, and is usually written in advance, it cannot reflect objective in time. The documentation is more effective. The demand document has at least the problem that the software is roughly resolved.
For low-cost clear demand, programmers must approach end users. This is more easily achieved in the free source world. Free source programmers will not be kept confidential because of worrying competitors, and will not retain some functions in the future as upgrade products.
However, in order to better work, end users can easily find and try new packages. In this direction, there has been some practical actions; for example, the GNU Configure System provides a general method of constructing a package. However, downloading and constructing a package and trying to be quite difficult and time consuming, in case it is not used to uninstall (in order not to lose data or system stability, it may also be recovered). It is difficult to find the channels that feedback. Existing package systems cannot really support this.
Create, imitate and copy
Something says that open source is more copying and expansion rather than creating from scratch. I don't believe it at all; some of the most innovative spirit software is from open development environment: arpanet, unix (Yes, UNIX is starting in a huge free environment), LISP MACHINE, and windowing system concept ( PARC). Moreover, not all innovations start from beginning, especially in the software world; no matter whether business or free software, most projects start on a certain job. I agree that the white hand is very likely to be more difficult - a team is working for a long time for a grand target without experience and financial support - there are few such projects. I have just mentioned the truly innovative free project has considerable external funding.
Is this really a blow to free source code? I do not think so. In the end, it is not important to be innovative as long as it is as good as the user. Linux is giving birth from Unix, using new and better implementations (in many ways, it is light than commercial UNIX products). GIMP started only an alternative to Adobe Photoshop; it developed in its own direction, now more powerful than Photoshop. In fact, one of the main objectives of object-oriented programming is to use the components to be more stacked. Many people didn't realize that this foundation depends on Aho, Weinberger and Kernighan (all three of AWK's three founders), as well as developers of other UNIX early tools. Using simple and universal data representation (ASCII text divided by space split), they construct a tool that can integrate use (shell scripts) to form a more powerful tool. Of course, this is not a real object-oriented programming, but this reflects the spirit of reuse.
This flexible construction and reuse tools are features that the software is different from other engineering directions. The cost of manufacturing hardware components - even is only very high on the foundation - very high. Renovate machines, cast new molds, design new packaging, not enough. In short, there is a new production line. If there is any shortcomings in the new parts, expensive resources are wasted, and the precious production time is also white. In contrast, the production cost of software unit is almost zero; only overhead is a design and implementation cost. This encourages freedom experiments and creative use existing components.
Anyway, as the essential characteristics of free source code, the sharing of code has greatly improved the robustness of this software development form. In fact, if there is any shortcomings, it is a place that is hard to find, and this defect is found to be a challenge. In order to make people easier to find the free source code they need, the demand for these large source code and cataloging work is very strong.
This also reveals why patent law and too harsh copyright law are potential threats for software, because these things inhibit the exchange of ideas and methods. The intention of the patent law is to grant the creator limited monopoly in its innovation field to encourage innovation. However, software is more intelligent and sensible to use existing methods, rather than huge innovation, so patent law actually hinders the innovation required for software.
Released as soon as possible, often release, or never release?
Manley also questioned the view of "released as soon as possible". He specially proposes pre-alpha (incomplete) software that is usually not streaming to the development group. He also claims that "as soon as possible and regularly release" and a regular release method are opposite. I don't agree with these perspectives - First, I believe that software development should be fully open (I will raise some examples); Second, as long as the correct implementation, I think this is a good release method.
First, it is necessary to understand the purpose of "release as early as possible". The purpose of this method is to make the expected user have the opportunity to trial and report the issue, or put forward new features, even add new features and feedback. However, simple and frequent publishing does not guarantee all this; if the project is generally poor, or if it does no one cares, these will not happen. If it is released too frequently to make the user feel discouraged, and they have not made enough contributions, this purpose cannot be achieved.
The company often has periodically released (may be once once every day, or once a month), and encourage interested employee trials. This is a form of "as early as possible," is not wide. At this point they are not different from the free source code.
Let us look at the goal from another perspective: Let users try new things. In front, I mentioned the iterative model of demand analysis: a prototype to the user and then modified according to feedback. Is the two close? Regular release users have the opportunity to feedback. However, to get a good effect, these must do it. Simple every night and inform everyone to upgrade; users don't know what will happen and will spend a lot of time to upgrade, soon you are bored. Those who don't want to do this should use the development database. In order to be more effective, the release should be like this:
Includes enough new features or corrected bugs. The interval is long enough to allow the user to use the current release. It is strong enough to complete (quality).
This is not to indicate that every release is excellent product, but each publishing should have excellent products: coherent, worth upgrading, and clean. Note that I didn't say it - as mentioned earlier, it is difficult to create a complete product.
There is still a benefit of doing this: it forces the developers to test, because the days are always close. This is nothing contradictory with a good release method, you need to do this.
Make the project too close to the development group - until the end of the end, allowing the outside world to use - means losing the ability to discover potential demand. There are two groups of cases form a sharp case, similar items, one disclosed release and the other:
Emacs
EMACS (Text Editor) - There are two versions that are derived from GNU Emacs, GNU Emacs and Xemacs, differentiated in the 1990s. GNU Emacs is developed by Free Software Foundation, while XEMACS is developed by a dispersed group. Differentiation is caused by issues such as copyright, and the development method has also have a thousand autumn.
GNU Emacs is developed by a small-scale development group of the Free Software Fund. Now, the 21 version has been developed for a few years; the current release is version 20.7.
Xemacs developed, stable and developed two branches in public, and a public web site. Current stable branches are 21.1.11, and the development branch is 21.2.35.
Xemacs has many different appearances (including embedded pictures and scalable fonts), and now the internal structure is also different; it has made a large extent, including character, event, and keyboard mapping. Reference: http://www.xemacs.org/about/xemacsvsgnuemacs.html. Note that this article may have some time, but many differences indicated are still exist.
GCC
GCC (C Compiler) - Free Software Foundation has developed GCC in a similar manner, and the final version is released. Developed in 1996 stagnant, because the entire project is invisible, no one knows what happened. A few years later, a team of Cygnus Solutions picked up existing code, adding some external patches, re-developing some parts, and issued EGCS (Experimental GNU Compiler Suite). This is developed in an open manner, progressing is rapid. Finally, this differentiate with the free software fund to transfer GCC to the EGCS team ended.
As mentioned above, the disclosed development model has the following advantages:
The task is more clear - people outside the project can observe the project, and the development group can continue to develop under pressure. More early tests. The expected developers are more attractive, which forms a broader developer's foundation.
However, Manley is still correctly illustrative of development (or pre-alpha), alpha, beta, candidate distribution, and distribution. Let's take a further look at the typical user foundation:
The developed version of the user likes the edge life, and will form the core user foundation of the new function, and it is necessary to see the response to its feedback. These users may have no interest to contribute code (developed), but sometimes these users will become developers. The user should understand the risk of the existence. The developer is responsible for explaining these risks. Alpha version is provided to those not so urgent (relative core users), but want to see what users are probably. Early users should try Alpha version, and have problems preparation, but the development group should conduct more training. The Beta version is provided to mainstream / early users, and their requirements for features and quality are higher, and they are willing to help test the final product. The development group should conduct considerable training for them. Candidates should be very close to the final release. The development group should provide support like the final release. The final release should have a considerable quality, and it should be satisfied with the project team in the end user's hand. As long as each developer and each user understand these - every stage expected, there should be no trouble should be. Usually, difficulties - the same is true for commercial developers - how to conduct proper training at each stage. The problem that frequently appears is that the training after the Alpha phase is too small; in the early training, it is too long, busy with the risk, causing the training to be long and there is no obvious results. Publishing engineers need to understand this process. This is irreplaceable.
According to my experience, regardless of business or free projects, it is often lost in the transition phase of Alpha to Beta, and the Beta phase is usually done. Often an early entered the beta phase (there is no sufficient completion of the project), and the Beta release phase is not sufficient (not enough time), and a clean product cannot be guaranteed. Beta should be complete. If there are too many problems (deep bugs or even missing requirements), you should withdraw from the Beta phase and properly retrospectively. If this is not accepted, it should be understood that this release is defective.
Linux's release is an interesting development process. Organized organizations in the manufacture is system integrators, also played monitoring development and integrating software packages to the positive role of the release. This is an interesting model that is also an enlightenment to free software development. The release is a useful feedback source that is being developed. If the distribution is almost the unified standards and practices that developers should follow, and the time to publish integration (package) in advance, this is a guide for developers. meaningful. Perhaps a Linux distribution version of a fee-free business can provide these services for free source projects that are not willing to do these troubles.
maintain
The first primary release is always easy. There is no known expectation; just start, the code is small, it is easy to work, everyone is excited for his work for the first time. The second release is difficult. People's enthusiasm is exhausted; I don't know what to do, and I have done it in the first release); the code is built on a complex basis; everyone is proud of doing these things; and the whole team has not Experience, I don't know what will happen next.
This is not only a problem with the free source code. I have seen the same problem in the project of the enclosed source code. I have participated in the development of new software products twice. Every time I saw the first release, the second is confusing. This is mentioned in business rather than technology, see Geoffrey A. Moore and Regis Mckenna's "Crossing The Chasm". I am not saying that there is all the answers in this book, but it puts at least a problem. Possible solution is to persevere and organize management. I am facing such problems in Gimp-Print; so far, our first release (4.0) is very successful, but the next step is much more.
Where is we going to go?
In order to inspire more thinking, I list some summary ideas and suggestions. Pure waterfall models are rarely applied to commercial projects, while applications in free projects. However, there are still some useful things, flexible use of certain steps are also beneficial. "As soon as possible and frequent release" has made many traditional internal releases in the free source code to locate the work. If the application is proper, this is good for the project, and there is indeed a classic case in history. Project leaders should emphasize the frequent convergence (source) to provide clean (not necessarily complete, not necessarily bug-free, but can be used), not to be obedient, this is very good Engineering training. The free software model has unique robustness, such as free sharing code, which is very conforming to contemporary development practice. However, for effective sharing code, the code must have certain quality and functionality. There are a lot of code that no one knows. If we can develop a system that catalogs for all code, people can get more ready-made components, as long as they do very few modifications, it can be applied, which will have a great help. Although some people often say that the free source code lacks innovation, the actual situation may be that the free source code is more good at Bo Cai, because there is no commercial strategic factor hinders its use of others. Good release project refers to the release of engineering, free source or other. Usually this is just a good self-training. The project is 90% of common knowledge plus 10% of expertise. Linux distributions and those who have profit from free source prodeers can provide more services for free source communities. Although this will be overwritten, this will also return them by providing quality and functionality. It is difficult to get beneficial feedback from the user. How to do it? WEB form, mailing list or feedback tool built in the program? If it is the last one, is it possible to construct a general feedback mechanism? The first release is always easier than the second. The first release is very exciting, and it is also the largest leap. How to surpass? Developers of free source (especially free software) are usually volunteers. How do we motivate them (actually us) instead of exactly how much pressure? What kind of organizational structure works best? What is the real development tool? How do we minimize the time of spiral advance? SourceForge is committed to this, but it is not perfect enough. Analysis SourceForge has made and not do what help. There are high-level meetings in printing and database, whether the free source project also needs such a senior meeting?
