By now, you've hypothetically followed me through the early programming of a piece of software, the creation of a website and system of documentation, and we've gone ahead and (as will be discussed in Section 4.3) released it to the rest of the world. Times passes, and if things go well, people become interested and want to help. The patches begin flowing in.
Like the parent of any child who grows up, it's now time to wince, smile and do most difficult thing in any parents life: It's time to let go.
Delegation is the political way of describing this process of "letting go." It is the process of handing some of the responsibility and power over your project to other responsible and involved developers. It is difficult for anyone who has invested a large deal of time and energy into a project but it essential for the growth of any free software project. One person can only do so much. A free software project is nothing without the involvement of a group of developers. A group of developers can only be maintained through respectful and responsible leadership and delegation.
As your project progresses, you will notice people who are putting significant amounts of time and effort into your project. These will be the people submitting the most patches, posting most on the mailing lists, and engaging in long email discussions. It is your responsibility to contact these people and to try and shift some of the power and responsibility of your position as the project's maintainer onto them (if they want it). There are several easy ways you can do this:
In a bit of a disclaimer, delegation need not mean rule by committee. In many cases it does and this has been proven to work. In other cases this has created problems. Managing Projects the Open Source Way argues that "OSS projects do best when one person is the clear leader of a team and makes the big decisions (design changes, release dates, and so on)." I think this often true but would urge developers to consider the ideas that the project leader need not be the project's founder and that these important powers need not all rest with one person but that a release manager may be different than a lead developer. These situations are tricky politically so be careful and make sure it's necessary before you go around empowering people.
Apache is an example of a project that is run by small group of developers who vote on major technical issues and the admission of new members and all have write access to the main source repository. Their process is detailed online.
The Debian Project is an extreme example of rule by committee. At current count, more than 700 developers have full responsibility for aspects of the project. All these developers can upload into the main FTP server, and vote on major issues. Direction for the project is determined by the project's social contract and a constitution. To facilitate this system, there are special teams (i.e. the install team, the Japanese language team) as well as a technical committee and a project leader. The leader's main responsibility is to, "appoint delegates or delegate decisions to the Technical Committee."
While both of these projects operate on a scale that your project will not (at least initially), their example is helpful. Debian's idea of a project leader who can do nothing but delegate serves as a caricature of how a project can involve and empower a huge number of developers and grow to a huge size.
If your project chooses to have branches (as described in Section 3.3), it might be a good idea to appoint someone else to be the the head of a branch. If you like focusing your energy on development releases and the implementation of new features, hand total control over the stable releases to a well-suited developer.
The author of Linux, Linus Torvalds, came out and crowned Alan Cox as "the man for stable kernels." All patches for stable kernels go to Alan and, if Linus were to be taken away from work on Linux for any reason, Alan Cox would be more than suited to fill his role as the acknowledged heir to the Linux maintainership.
As the person managing or maintaining the project, you aren't the person who is going to be making a lot of patches. However, it's worth knowing about ESR's section on Good Patching Practice in the Software Release Practices HOWTO[ESRHOWTO]. I don't agree with ESR's claim that most ugly or undocumented patches are probably worth throwing out at first sight--this just hasn't been my experience, especially when dealing with bug fixes that often don't come in the form of patches at all. Of course, this doesn't mean that I like getting poorly done patches. If you get ugly -e patches, if you get totally undocumented patches, and especially if they are anything more than trivial bug-fixes, it might be worth judging the patch by some of the criteria in ESR's HOWTO and then throwing people the link to the document so they can do it the "right way."
A firm knowledge of the scope of your program (that's the "idea" I talked about in Section 2.1);
The ability to recognize, facilitate, and direct "evolution" of your program so that the program can grow and change and incorporate functionality that was originally unforeseen;
The necessity to avoid digressions that might expand the scope of the program too much and result and push the project toward an early death under its own weight and unwieldiness.
These are the criteria that you as a project maintainer should take into account each time you receive a patch.
Fogel elaborates on this and states the "the questions to ask yourself when considering whether to implement (or approve) a change are:"
Will it benefit a significant percentage of the program's user community?
Does it fit within the program's domain or within a natural, intuitive extension of that domain?
The answers to these questions are never straightforward and its very possible (and even likely) that the person who submitted the patch may feel differently about the answer to these questions than you do. However, if you feel that that the answer to either of those questions is "no," it is your responsibility to reject the change. If you fail to do this, the project will become unwieldy and unmaintainable and many ultimately fail.
Rejecting patches is probably the most difficult and sensitive job that the maintainer of any free software project has to face. But sometimes it has to be done. I mentioned earlier (in Section 3 and in Section 3.1) that you need to try and balance your responsibility and power to make what you think are the best technical decisions with the fact that you will lose support from other developers if you seem like you are on a power trip or being overly bossy or possessive of the community's project. I recommend that you keep these three major concepts in mind when rejecting patches (or other changes):
The idea of stable and development branches has already been described briefly in Section 2.4 and in Section 3.1.1.3. These allusions attest to some of the ways that multiple branches can affect your software. Branches can let you avoid (to some extent) some of the problems around rejecting patches (as described in Section 3.2) by allowing you to temporarily compromise the stability of your project without affecting those users who need that stability.
The most common way of branching your project is to have one branch that is stable and one that is for development. This is the model followed by the Linux kernel that is described in Section 2.4. In this model, there is always one branch that is stable and always one that is in development. Before any new release, the development branch goes into a "feature freeze" as described in Section 3.4.1 where major changes and added features are rejected or put on hold under the development kernel is released as the new stable branch and major development resumes on the development branch. Bug fixes and small changes that are unlikely to have any large negative repercussions are incorporated into the stable branch as well as the development branch.
Linux's model provides an extreme example. On many projects, there is no need to have two versions constantly available. It may make sense to have two versions only near a release. The Debian project has historically made both a stable and an unstable distribution available but has expanded to this to include: stable, unstable, testing, experimental, and (around release time) a frozen distribution that only incorporates bug fixes during the transition from unstable to stable. There are few projects whose size would necessitate a system like Debian's but this use of branches helps demonstrate how they can be used to balance consistent and effective development with the need to make regular and usable releases.
In trying to set up a development tree for yourself, there are several things that might be useful to keep in mind:
Debian may be able to make good use of four or five branches but it contains gigabytes of software in over 5000 packages compiled for 5-6 different architectures. For you, two is probably a good ceiling. Too many branches will confuse your users (I can't count how many times I had to describe Debian's system when it only had 2 and sometimes 3 branches!), potential developers and even yourself. Branches can help but they come at a cost so use them very sparingly.
As I mentioned in the preceding paragraph, different branches will confuse your users. Do everything you can to avoid this by clearly explaining the different branches in a prominent page on your website and in a README file in the FTP or web directory.
I might also recommend against a mistake that I think Debian has made. The terms "unstable," "testing," and "experimental" are vague and difficult to rank in order of stability (or instability as the case may be). Try explaining to someone that "stable" actually means "ultra stable" and that "unstable" doesn't actually include any unstable software but is really stable software that is untested as a distribution.
If you are going to use branches, especially early on, keep in mind that people are conditioned to understand the terms "stable" and "development" and you probably can't go wrong with this simple and common division of branches.
Like a lot of this document, this should probably should go without saying but experience has taught me that it's not always obvious to people. It's a good idea to physically split up different branches into different directories or directory trees on your FTP or web site. Linux accomplishes this by having kernels in a v2.2 and a v2.3 subdirectory where it is immediately obvious (after you know their version numbering scheme) which directory is for the most recent stable and the current development releases. Debian accomplishes this by naming all their distribution with names (i.e. woody, potato, etc.) and then changing symlinks named "stable," "unstable" and "frozen" to point to which ever distribution (by name) is in whatever stage. Both methods work and there are others. In any case, it is important that different branches are always available, are accessible from consistent locations, and that different branches are clearly distinguished from each other so your users know exactly what they want and where to get it.
Other smaller issues that are worth mentioning are:
For those projects that choose to adopt a split development model (Section 3.3), freezing is a concept that is worth becoming familiar with.
Freezes come in two major forms. A "feature freeze" is a period when no significant functionality is added to a program. It is a period where established functionality (even skeletons of barely working functionality) can be improved and perfected. It is a period where bugs are fixed. This type of freeze is usually applied some period (a month or two) before a release. It is easy to push a release back as you wait for "one more feature" and a freeze helps to avoid this situation by drawing the much needed line in the sand. It gives developers room they need to get a program ready for release.
The second type of freeze is a "code freeze" which is much more like a released piece of software. Once a piece of software has entered a "code freeze," all changes to the code are discouraged and only changes that fix known bugs are permitted. This type of freeze usually follows a "feature freeze" and directly precedes a release. Most released software is in what could be interpreted as a sort of high level "code freeze."
Even if you never choose to appoint a release manager (Section 3.1.1.2), you will have an easier time justifying the rejection or postponement of patches (Section 3.2) before a release with a publicly stated freeze in effect.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |