FreeBSD/core Membership
Contents
What is the core team?
The FreeBSD core team is a group of elected FreeBSD developers that manages the FreeBSD project. They are responsible for setting direction of the project, for managing the developer base, for resolving conflicts and for being good role models to the community. They are elected every two years by the FreeBSD developer community, and are supposed to represent the interests of that community in their official actions.
The FreeBSD/core team manages the project as a whole. In theory, they set the long term goals and agenda for development and then delegate the implementation of these goals to the appropriate teams. In reality, the groups of developers doing work in a particular area tend to have an even greater say in the direction of the project. The core team has historically recognized this and gives great deference to active, productive members of the community in matters of direction. Core, and its members, encourage the developer community to work together towards a consensus driven final goal. Core rarely explicitly endorses these goals, but often takes note of progress or its lack in areas important to the project.
Sometimes, these informal groups within the project band together to form a long-term subgroup within the project devoted to release engineering, security, ports, documentation, etc. When these groups form, when they are stable and when it is important for the project that some sort of official recognition be granted to these groups, the core team will grant these teams a charter that describes their duties. The charters tend to be vague in the hopes that the intention of the charter carries more weight than the details and language lawyering would. These delegations often include the ability to cut through the normal procedures that core has put into place to help promote harmony in the project. These groups generally have been deemed to be responsible enough to have fewer restrictions placed upon them. However, this freedom does come with a price. Core can and does review the actions of these groups from time to time or when there's a complaint. Core relies on the existence of these reviews to keep honest people honest. Core relies on the reviews to limit the damage that poor decisions by the teams causes and to provide a forum for legitimate complaints to be heard and reviewed. The core team historically has had a fairly hands off management style, trusting members of these groups to be responsible and to perform at a higher level than others in the project. Even with its hands off style of management, core has needed to intervene from time to time. There's every reason to expect future intervention will be necessary.
The core team also is a convenient whipping boy for those in and around the project that don't like what is going on in the project. Clearly it is core's fault, and if they could just fix it, life would be better. Once you are on the core team, however, you'll discover that the ability to fix things depends much upon persuading people to do work. That can be much easier said than done.
Developer Relations
FreeBSD is an all volunteer organization. This means that the core team has a limited ability to cause things to happen. In a paid environment, the management team can threaten termination if an employee doesn't perform. In a volunteer organization, one must build up good will to get things done. If good will and gentle persuasion are insufficient, then additional means to force compliance with accepted norms of behavior are needed. However, core's options are somewhat limited. Two options are available to core when dealing with a trouble maker who doesn't respond to reason. One is public shame, where the trouble maker is exposed in public. This can work to shame the person into behaving correctly. It can also enrage the person further, so care must be taken in using it. The second one is removal from the project. This is a very drastic step, and should only be undertaken when absolutely necessary to protect project harmony. If the trouble maker is a person to whom core has delegated added authority and responsibility, a third option is available. Core can revoke that delegation and assign it to someone else. This is the primary means by which the core team can ensure that those in the project in a position of authority (say ports manager, security officer, release engineer, or other so-called "hat") are held accountable for their actions. However, firing a "hat" can have big consequences to the project, so extra care must be taken when selecting people for these positions of authority.
Core's opinion, however, can carry much weight. Several years ago, there was much discord among developers. Many fights were breaking out and there was much animosity. Core stepped into these disputes and put an end to them by showing clearly that the bad behavior wouldn't be tolerated. We even had to kick one person out for extremely bad behavior when he showed unequivocally that he couldn't work within the structure that he was expected to work in. Apart from this extreme case, core has been able to control behavior for the most part with a series of lectures, some arm twisting, phone calls to people in conflict and the occasional public tantrum.
Public shame is a tough one to wield. When one shames someone, that can have anywhere from no effect to a devastating effect depending on how it is done and where it is done. The Internet has a memory, so anything that's published far and wide can have repercussions long after the event. When we put people into the 'sin-bin' or timeout-box, we found that this information propagated far beyond what we'd intended and we had to find better ways to put people in the box. In time, however, we found that putting people in the box had a diminishing return on affecting their behavior and the behavior of others. Now it is reserved as acting as a firewall to someone who is actively damaging the repository. Less serious uses are handled in other ways.
The core team has never had to dismiss anybody from a position which they hold in the project. We have had to remind an office holder once that they serve at our pleasure and can be replaced. Even using that phrase can make it sound too much like the political cronyism that exists in some large industrialized countries. While it is accurate to describe the situation (officers serve so long as we like what they do and don't do), the phrase is too emotionally charged. Core is everybody's boss in this project, and we have final say over their actions as they relate to the project's resources. Everyone is expected to behave. Office holders are expected to behave to a higher standard, and will often get a reprimand from core when they do the same things that non-office holders do not.
Finally, core team members should remember that they were elected to serve the project. They were elected to help make this a better place to do work. Care should be taken to avoid abusing the position of authority to abuse people in the project. While normal inter-developer relations can cause enough bad blood, inter-developer conflicts with core team members carry an added emotional charge. Core members are held to a much higher standard of conduct, both by their fellow core members, and by the developer community as a whole.
Commit Bits
Core's primary job these days, apart from dispute mediation, is to hand out and remove commit bits. Commit bits are handed out to individuals who are deserving and have volunteered to do work for the project. We expire unused commit bits for security reasons. When to expire a commit bit can be a tricky issue. On the one hand, it pays to have more people that are favorably disposed to working on the project. On the other, many internal discussions have been leaked to the outside world. Those discussions may have been leaked by the more idle committers, perhaps by some that have become disillusioned with FreeBSD and just want to cause trouble. There's a lot of cachet with being a FreeBSD committer, and many folks who contributed a lot of code to FreeBSD in its early days wish to remain connected to the internal development mailing lists.
When contacting developers about retiring their commit bits, start out by asking if there are problems that are getting in the way of their committing that can be solved. Many times there have been no commits due to access to the cluster. Other times, the problems can be personality conflicts within the project. Most often, however, life gets busy. Give the committers a chance to commit something to show they are still interested in the project. If they say they are going to do something, give them an opportunity or three to prove what they say before retiring the commit bit. In the case of valuable committers that are idle for a long time for external reasons, work with them to make sure that when they have the time and energy they can resume their work.
Core team members should carefully consider candidates to get a commit bit. They should evaluate the candidate in terms of the contribution to FreeBSD, their interactions on the list, their ability to work within the sometimes chaotic, sometimes frustrating, sometimes frenetic environment that is the FreeBSD project. They should consider how well the mentor has behaved in the project, as well as the mentor's maturity level. They should consider the applicant's maturity level as well. Remember, the mentor is the first line of defence when disputes happen, and his or her ability to resolve them will generally determine how well new committers integrate into the project.
Core deliberations
Core tries to do everything it does via consensus. The ideal that is held out is that everybody has their say and the proposals are modified to make everyone happy, within reason. There are times that a 8-1 split will come up and making that '1' happy would make the proposal useless. While most issues are voted upon and are unanimous, that's not required.
For lesser issues, often times it is assumed that one or two core members acting alone is sufficient to make sure that nothing stupid happens. Core members doing these sorts of things should send out email asking for objections. If there are objections, then core should more fully discuss the matter. Otherwise, the core member should go ahead with the action. 24 hours is enough to make sure that enough people see the problem to object. The idea here isn't that everybody always gets a 'veto' on the lesser matters: rather, that enough of core has a chance to sanity check it before any harm is done. The basic belief is that as you get more of core to check it, the saner things will be. Most core members are basically sane, and their collaboration has an additive effect on the saneness of their judgment (although prolonged exposure to core can drive people insane).
Long Term Projects
Many core team members have a long term project or agenda they wish to further by being on the core team. These activities usually are a plus for the project as a whole. However, some caution is advised. Being on the core team, at times, can suck up a lot of time. Whenever there's a hot dispute cooking, much time and energy is put into resolving the dispute. Even just reading the core mailbox can consume a lot of time. And it seems that these disputes flare up just when you need to get something else done and that long-term project suffers. If you are on the core team, expect disappointment like this.
Dispute Resolution
The art of dispute resolution can be a tricky one. The core team should, early in its tenure, establish a policy on how to handle disputes. It should be clear to everyone on the core team what the appropriate reaction to a new dispute should be and who should make it. It is advisable to make one person responsible for doing the lion's share of the negotiations with the parties involved. These negotiations should cc core, however, to ensure that the person doing the negotiations doesn't get off into the weeds, and also to ensure that the rest of the core team knows what's going on. This last bit can be important if the primary flakes out for whatever reason.
It is usually best to get both sides of the story. There will usually be some technical problem to solve as well. This will be the easy part of the dispute, typically, as reasonable people tend to come to consensus faster on how to do something than they do on getting over the hurt feelings from the dispute. Often times the bigger and harder piece of the puzzle is understanding the interpersonal stuff that's going on in the dispute and to get a handle on the situation to limit further damage and to hopefully reverse the damage done before the folks approached core.
Almost always, by the time the dispute gets hot enough for core to hear about it, much damage has been done. And often times both parties have behaved badly along the way to get to this point. In these cases, it is often best not to assign BLAME, but rather work towards getting each party to understand and acknowledge their part in the dispute. And to apologize or do whatever other actions necessary to remeditate it. It is important also to not let understanding equate with a free pass. The moderator needs to understand what is going on, but also needs to hold the parties to account for their actions.
If you are extremely lucky, there will be no 'problem children' during your tenure on core. So far, not one core team has happened without at least one problem child, and usually multiple problem children. Experience has shown that the best approach of these situations is to appoint a special care-taker core-team member to look after the problem child. This can be quite useful, as the problem child often needs some behavior modification, but also needs someone they can turn to when things get bad that can help them out of the bad situation. The care-taker should help them out in a healthy and supportive way with positive suggestions for how to resolve the situation. These relationships are hard to build, and can take a huge amount of time. However, over the long term, they can really help problem children integrate back into the FreeBSD community. We are proud that we have many former problem children who are now model citizens of the community due to the efforts of care-taker core-team members. History should be remembered.
Project Leadership
Serving on the core team places you at the highest levels of the FreeBSD project power structure, such as it is. You are a leader for the rest of the project. You must act like a leader. In the United States, and other countries, the leadership usually sets the agenda and forces it down the throats of the rest of the country (with varying degrees of force or finesse). The actual setting of the agenda may involve public input, public negotiations, private deals, etc. There's much behind the scenes action in the politics of a large country, and much opportunity for citizen input. However, given the large number of people in the country, only a vanishingly small number get direct input. This is why the leadership casts the issues of the day and works to make them happen. They choose which things to pursue and what to present to the country as the issues of the day. While a limited amount of mavericks can do good, typically those that play the power game are rewarded with a share of power. The focus, it seems, is on the power, wielding the power and/or stopping the other guys from wielding the power. It is about creating a persona of power, and cultivating a cult of personality among the masses so they will vote for you in the next election.
In contrast, to be a leader in the FreeBSD project requires a different type of leadership. In the FreeBSD project, a leader is someone who is in tune with the group's voiced and unvoiced desires and helps to give them a coherent voice. A leader is someone whose public actions are worthy of emulation by the rest of the project. A leader puts aside ego and works for the betterment of the project. A leader is not afraid to admit mistakes when they are made, yet stick to their guns when necessary.
The core team typically doesn't issue manifestos. There's usually very little direct communication from core. The core team is a committee, and getting public statements through a committee can be difficult. Instead, most of the project will judge how effective the core team is being by how effectively its members operate in public and private. A good leader has a good sense of what to post publicly and what to post privately. A good leader knows when to call someone on the carpet privately in email (or over dinner, or in a phone call), and when a public reprimand is necessary. A good leader knows how to listen to the competing points of view and to understand where each of the parties is coming from. A good leader then uses wisdom to form opinions about the issues. A good leader is ready to revisit those opinions that have become obsolete. A good leader will have their say, but let others have their say: the last word isn't necessary.
Since the core team does have private deliberations, there are times that it will set an agenda for the project. Sometimes this agenda is disclosed explicitly, other times only parts of it are disclosed. When we had very bad developer relations a few years back, the core team got together and decided that it was time to draw a line in the sand for this behavior. We announced this and started to enforce standards of behavior. We debated at length about what these should be. Those that participated in the debate came away with a good gestalt about when to act and when to let conflict play itself out. This commitment to the will of the group helped steer the project back on track. The exact boundaries weren't ever explicitly disclosed, however. Each core member knew them at an intuitive level. Had core desired, it could have issued detailed instructions. However, part of leadership involves giving people the basics and trusting them to have the intelligence and wisdom to apply those basics to get along well. When people fell outside the range we'd established, we did police them. Sometimes in private, sometimes in public, but not all of the actions were disclosed to the larger group. Only when disclosure would further the desire of the core team for better working relations were let out. On the one hand, there were several folks that oopsed and mended their ways never to need oversight again. These were the success stories of this policy. On the other, there was at least one extreme case where the core team didn't disclose the bad behavior that lead to our disciplinary action. In this case, the affected person was later able to paint a very different picture of what happened and to spin it in a way that most on core don't agree with. Had we to do it over again, in this one case, we'd have disclosed more.
Leadership also involves spending time on the project that isn't directly on managing the project. By keeping one's fingers in the technical side of the project, one stays connected to the people of the project. One picks up the buzz in the project. In time, one learns to distinguish the mundane problems that sort themselves out from the real fires that need to be put out. The core alias can be useful in the borderline cases. Often times someone will post something in private to the list as a fyi before a situation evolves into a crisis. Sometimes some indirect pressure is applied, other times nothing is done. The collective wisdom of core acts to moderate extreme actions and to help keep individuals from going off track.
The core TEAM
One should view the core group as a team. Everyone on the team is there because they want the project to succeed and become better. Often times there's much debate about the proper course of action. Sometimes everyone is instantly on the same page. However, when the team decides something, the other members of the team are expected to enthusiastically implement those decisions. Since the core team operates on a consensus model nearly all the time, everyone on the team has a chance to pipe up with their opinions. This can be a little disconcerting sometimes if one member is behind on their email and suddenly injects new life to a discussion that was winding down (hint: read the entire thread before replying to minimize these effects).
In addition to the core team acting as a team, team members are trusted to have enough wisdom and maturity to act when necessary. There are many times that fast action is necessary to help firewall a situation, or to resolve a trivial issue. When these issues come up, team members are expected to deal with the situation professionally, and also to inform the rest of the team of their actions. In the pre-elected days of core, unilateral action lead to many problems. Since the election, very little unilateral action has happened as a result. One or two fellow team members acting as a sanity check to actions has helped to have only the right actions happen. It has also fostered more of a team spirit among core members, since they know they aren't facing the problem alone. In addition, knowing there's accountability for bad actions, many sanity checks have resulted in the proper non-action happening.
New members should take special care to keep the other members of the team in the loop. This isn't to keep new members under someone's thumb. Instead, it is to allow the more senior members a chance to explain history behind situations. Often times jumping in and solving a problem without this history can make the situation worse. It can also lead to needless friction between core members as the senior member who may have negotiated a settlement before feels like their toes are stepped on. Early communication can help these problems from blowing up.
Finally, email sucks. There will come a time when the ability to effectively communicate in email breaks down. It will happen. It has happened. To every member of the core team, it seems. When it does happen, pick up the phone and call someone. Call the person that you are having trouble communicating with. Have a conference call with core. Voice communication also reminds us that we're human, and the we like to go down to the pub for a pint like everyone else. When conferences happen, make special efforts to seek out other core members and be social. The bonds that form will help if there are bad times. Finally, at conferences, have one person autocratically pick where to go. We learned the worst way to pick a restaurant to eat at is when you have 9 people with either complete apathy, or mutually exclusive opinions. Trust one person to make the call, and rotate that job.