There are 22 candidates running for 9 places on the core team: Alfred Perlstein Benno Rice Brian Somers Matt Dillon Brian Feldman Greg Lehey Gregory Sutter Warner Losh John Baldwin J. Mallett Jun Kuriyama Mark Murray Makoto Matsushita Mike Barcroft Murray Stokely Nick Sayer Paul Richards Peter Wemm Ollivier Robert Robert Watson Scott Long Wes Peters ---------------------------------------------------------------------- Alfred Perlstein Last modified: May 20 22:08:21 2002 I believe that FreeBSD is doing Ok. However we need to address some key issues: o) Getting a handle on the 5.0 release, we need to address the performance and stability issues now. o) More aggressive advocacy. We need someone to step up at the next conference to be vocal and POSITIVE about FreeBSD and its future. I feel confident that I will be able to do so. o) The ability to make decisions quickly without soaking up endless hours of developer time. o) The ability to limit the ability of individuals in and outside of the project from having a negative impact on our developers and public relations. This includes people that are disruptive on the mailing lists and in the CVS repository. They need to be asked to tone it down and failing that have their privileges revoked. I'd like to bring some respectability back to the project. I am appalled that people who have just joined the ranks or who have just returned from self imposed exile are now running. We don't need these drama queens making more of a mess, what we need is leadership. We need a voice for those that are valuable contributors but who are being pushed out by these types. A voice that will gladly tell people to "sit down and shut up" when their rhetoric gets out of hand. I really don't think anyone else will have the guts to tackle these issues. Therefore it is important that you vote for me. Using FreeBSD since 2.2.2. Added to avail (became a committer): Revision 1.105, Wed Aug 11 19:37:18 1999 UTC (2 years, 9 months ago) by jkh /home/ncvs/CVSROOT/commitlogs % zgrep ^alfred * | wc -l 666 # >;) I have my fingers in most places where FreeBSD needs a bit of help, past projects have included working on: SMP scalability, pthreads, NFS, ported NFS lockd to FreeBSD, miscellaneous drivers (if_wi, usb). I've also done my fair share of advocacy including: Provided a step-by-step guide to net booting FreeBSD systems for install or lab deployment. Gave presentations at Google (http://www.google.com) and Jarna (http://www.jarna.com/). http://people.freebsd.org/~alfred/pxe Integrated and improved Yahoo! (http://www.yahoo.com) 'accept filter' kernel technology into FreeBSD. -Alfred Perlstein ---------------------------------------------------------------------- Benno Rice Last modified: May 15 02:51:43 2002 I've been a FreeBSD user since 1996 (2.1.5) and a committer since November 2000 (circa 4.2-RELEASE). I was given my commit bit to work on porting FreeBSD to the PowerPC family of CPUs, in particular the Apple Macintosh platform, a project which is getting closer to seeing the light of day. =) I see -core as needing to be the group that ensures the smooth running of the project in the best way it can with the least interference to the work of the developers. To do this it needs some measure of power, but it's use of that power should always be accountable to the developer community as a whole. The purpose of the -core team should be to resolve issues on behalf of the FreeBSD development community as a whole in a timely and accountable manner, and to ensure that being a part of the project is as rewarding as possible. ---------------------------------------------------------------------- Brian Somers Last modified: May 15 01:27:55 2002 I've been a member of the BSD community for the past 9 years, and have been a FreeBSD committer for 5.5 of those years. I've seen the project move downhill from being politically sound, and believe I can help to give back some sanity. I realise that a core role is primarily political. I don't see myself as adding to the politics, but rather as a stabilising element. My claim as an appropriate candidate is that I am 100% dedicated to things I have committed to. Core needs active members, and core needs to stop the infighting -- without reducing the size of the active committer base. I believe I can help in these areas, and can fulfill the other core responsibilites. ---------------------------------------------------------------------- Matt Dillon Last modified: May 29 21:45:17 2002 From the very beginning of my involvement in FreeBSD, starting around 1993, I have stood proxy for many of the end users and sysops who use our distribution, helping people track down and fix bugs and working on the system with the primary goal of producing a stable, uncrashable kernel. It has always been my feeling that stability should be our number one priority. I have also come to believe, through my own experiences, that core rules and policies have not been dealt out with an even hand and that the ultimate goals of the project and intra-developer relations within the project have been warped by politics, personal agendas, and even some elitism which runs counter to the project's general health. I am most well known in the community for my NFS, VM, and filesystem work. Most of my FreeBSD work is kernel-oriented. I am also well known outside of the FreeBSD community for my involvement with BEST Internet the Diablo news system, 'cpdup', many old Amiga related projects (DICE, DMouse), and in the Linux community for 'dcron' and early TCP work. As a member of core I will do my level best to address these issues as well as any issues brought up by our development and end-user community. My current position is to promote and support the following: * A greater emphasis on stability in the -stable series. * Better end-user relations with regards to handling problem reports and better developer relations with regards to avoiding 'surprise' commits that are becoming more common due to the high volume of commits (aka formalizing my 'pull' notification system previously discussed on the lists). * Better intra-developer relations by using my vote to attempt to remove the rule-created elitism that has crept into the project. I feel quite strongly that there must be a separation between administration and code development. Rules must deal with administration and developer relations (common courtesy) and should not impose an open-ended pecking order for code development. I believe it might also be helpful for me to state my position on specific efforts within the project itself. Specifically, while I intend to promote stability as a member of core I still recognize that stability must not be an overriding factor for the project. New development must continue. To that end I am 100% behind existing 5.0 related efforts including SMPNG, UFS2, and the recent syscall vector discussions (the creation of a new syscall vector to deal with major 32->64 bit size changes for time_t and other elements). 4.0 gave us a wonderful, extremely flexible base and has proved its longevity. By introducing these major changes now we will give 5.0 the same abilities and a longevity that will almost certainly exceed that of the 4.x series. A central debate topic seems to be emerging from list discussions in regards to the desire that core members work well together. Despite attempts to characterize it otherwise, core is and always will be a political entity of sorts. It is perhaps not as political as the term implies, we are after all just engineers and coders at heart and we would all prefer to just be able to do our own thing, but politics are an integral function of any governing body and one is certain to head into dangerous waters if one attempts to deny that aspect of what core is. I believe it is important to consider the ability of core members to work with each other civily. One must also keep in mind that there is a distinction between honest differences in opinion and interpersonal hostility... that is, decisions colored by one's personal feelings to a claimant or to other core members verses decisions based on platform or idealogy. We want to end up with a core that is able to have productive internal conversations but we do not want to end up with a cabal or an old-boy's club which misrepresents the asperations of our user and developer community. I believe that the issues people vote for in this election will bring core together far better then a list of recommended compatriots would. My pledge to the developer community is that I will meet these high standards and I will make diplomacy a priority if/when issues brought before core turn vitriolic. It is in fact one of the main reasons why I am running. I feel quite strongly that the FreeBSD project has become too elitist in the past few years and one of my primary goals as a member of core would be to correct that. RULES BASED ELITISM - EXTRACT One of the many serious problems I would like to address is what I call rules-based elitism. That is, one developer quoting rules on the lists as a justification to create an imposition on another developer with regards to material that the first developer is not otherwised engaged in development on. Rules are a double edged sword. We need rules to establish order, but rules can also be misused to create disorder and elitism within the community. A significant problem with the rules we have now is that they make very little distinction between what should be required of a developer and what should simply be a strong suggestion, or mold that we wish developers to grow accustomed to and follow. The strongest support expressable in our community is advancement of the FreeBSD project through commits made to the tree, and as a community we must both encourage such work and maintain order in the project. Rules based elitism creates disorder in the project and worsens the atmosphere on the lists. For example, here are three statements complaining about an aspect of a commit that violates a rule. See if you can pick out the elitist one: * Hi X, I've reviewed your patch and would like you to separate out and commit the whitespace & bracing changes separately, as per our rules. * Hi X, I tried to review your patch but you have a huge number of whitespace & bracing adjustments mixed in with the meat and I am having a hard time separating them out, could you separate those adjustments out into a separate commit? Thanks! * Hi X, I've reviewed your patch and it looks good. It would be nice if in the future you would separate out whitespace and bracing changes and commit those separately, but don't worry about it this time around. It should be fairly obvious that it is the first one. Now consider how these statements would play out on the lists. Keep in mind that there are two classes of people doing real work here... the developer who is doing the work, and the developer(s) reviewing the work. And then there are developers policing the work for rules violations. In the context of this paritcular example we as a community need to throw our support behind the people doing the actual work. That not only means being civil on the lists, but it also means separating out the real issues from the garbage and properly prioritizing them. Someone simply quoting rules, even over the most minor of infractions, is not being helpful to the development process. On the otherhand, someone trying to review work who is having real trouble due to some rules breakage by the developer can legitimately ask that developer (that is, impose on the developer) a request that the developer do further work prior to commit. Then, finally, a developer reviewing work who feels only a slight imposition due to a rules violation should take tact 3... *not* impose extra work on the developer who did the original work but try to nudge that developer into making it easier on people the next time. As a core member I will attempt to have our rules clarified and separated into distinct categories, and clarify what is considered to be appropriate etiquette as a means to improve interactions on our public lists. Thank you for your consideration, -Matt ---------------------------------------------------------------------- Brian Feldman Last modified: Jun 11 15:55:23 2002 As a committer for almost three years, I think I can provide a valuable benefit to FreeBSD community by being on core with a significant amount of FreeBSD experience but a less entrenched (one may say less religious :) viewpoint on most of them. I would like to be able to objectively help resolve issues, most especially on the things I am less experienced with, because of this. To continue on with answering the questions posed explicitly, I expect that I will end up spending 5-10 hours a week generally on core-related issues, and willingly attempting to limit emotional involvement. In the worst case scenario, I could see easily being able to devote twice that to core if the need truly arose. As a member of core, I feel I can help solving the problems that occur when shaping the direction of FreeBSD, from a higher level; I believe I could be more effective in helping to manage the resources we have than stretching myself to individually attempt to commit large parts of my resources to each. If I am on core, I do not actually expect to do less than I am doing now. I expect to ramp back up spending more time on FreeBSD in general as my life starts settling back down again. If my time from core had to detract from something, it would probably detract from my ability to follow some of the more esoteric issues on the mailings lists. I don't think I would be any less motivated to continue as I've been doing and attempt to fix bugs (which, frankly, I think has become one of the things I'm more valuable at doing) or whatever else as the need arises. The mailing lists I intend to be on are the same as now: -arch, -current, -hackers, -standards, and security-related lists (but not -security in its current form; I believe strongly that it needs to be refactored or moderated). If I find myself able to start following its specific current issues and needs, -stable would be the next for me to start reading. If anyone thinks there are more questions that should be posed to all candidates, please do so and I will answer them to my best abilities! ---------------------------------------------------------------------- Greg Lehey Last modified: May 15 09:18:12 2002 I've been in the industry for nearly 30 years, during which time I've done just about everything there has to be done, including managing a "team" of particularly aggressive cats. I've been using BSD for over 10 years, and first started using FreeBSD in early 1994, though I didn't really get involved until in late 1995, when I was asked to write the book which became "The Complete FreeBSD". I'm also the author of the Vinum Volume Manager, and I write a bi-monthly series "The Daemon's Advocate" in Daemon News (shared with Wes Peters in alternate months). I've also done a lot of advocacy work for FreeBSD, particularly in East Asia and Australia, and I'm the Secretary of the Australian UNIX User group (http://www.auug.org.au/), and have been elected as president starting on 1 July 2002. For more information about me, see http://www.lemis.com/grog. The FreeBSD project is changing significantly, and I think that a number of well-intentioned people don't recognize the fact. This is the root of a number of problems that we've been having. In order for the project to evolve, we need to recognize and address a number of issues, mainly due to the maturity of FreeBSD. In the early days, there were enough obvious problems to address, and there were relatively few committers. Now FreeBSD is a stable operating system, and increasingly development work concentrates on improving currently functional system components, requiring coverage of a larger proportion of the code base by a larger number of committers. This gives rise to a number of issues: 1. Technical and interpersonal conflicts are becoming more common. Core must improve its handling of these problems. 2. There are plenty of ways to improve subsystems. Currently the method adopted is the one proposed by the committer who can shout the loudest. This is not necessarily in the interests of the project. We need more project management, at the very least an architectural review board which ensure that we're not shooting ourselves in the feet. We also need to recognize that the project is not just the committers. One of the problems of the committer-centric view is that functionality tends to get dropped if it doesn't suit particular committers. This can be very frustrating for end users. The architectural review board should address this issue as well. 3. Like it or not, core is management. A number of people in the last core got frustrated because of this, and a lot of the frustration came from an unwillingness to accept the necessity of management ("red tape", "nit-picking"). Certainly, the FreeBSD project is very different to other development models, but I can't see any reason why traditional management techniques won't work here as well. I encourage people to vote for candidates with at least *some* management background. Note that none of these core duties involve writing code. Management in commercial companies doesn't involve writing code. It shouldn't in the FreeBSD core either, though obviously there's nothing wrong in having studly coders on core: it's just that it shouldn't be considered a criterion for core membership. ---------------------------------------------------------------------- Gregory Sutter Last modified: Jun 7 04:39:14 2002 Background ---------- I've been a BSD user since 1994, when introduced me to FreeBSD, causing me to abandon Slackware. I have been a doc committer since 9 Feb 2000. I'm one of the founders of Daemon News and am currently an officer and board member. My day job is with NextGig, Inc., in San Diego, CA, US, where I work alongside many of the former BSDI engineers on a database optimization product (which uses FreeBSD). In short, I have FreeBSD experience as a user, an administrator, a contributor, a committer, and, perhaps most important for a core team candidate, as an experienced advocate. Core's role in the FreeBSD Project ------ ---- -- --- ------- ------- I am running for core in the hope of helping to make it, or keep it, successful in the following ways: - As an arbiter of disputes between committers. This seems to be one of core's primary functions. Commit wars, for example, are a completely unacceptable use of the Project's resources. Mailing list arguments which go from technical grounds to personal, or which become nothing more than restatements of ideas that have already been put forth, should be redirected by carrot or by stick into more productive uses of time, hopefully ones which continue to benefit FreeBSD. - As a redirector for queries and delegator of tasks that can better be resolved by another party. From looking at Wilko's core reports, it seems that the team gets a lot of mail about things that could be beneficial to FreeBSD, but are not a responsibility of the core team. Core's function here should be to introduce the external party to the group, mailing list, or individual best suited to handle the request... and, equally important, to perform periodic status checks to ensure that the matter hasn't been forgotten. - As a source of social direction for the project. There are no specific rules about how committers must interact in public, just the Committers' Big List of Rules in the committers' guide. Core members must recognize that, first, their behavior should _always_ be in harmony with those rules, and second, that they are often role models for committers and contributors. The committers' rules are quite good, and extremely important. (Many committers could really use a refresher on rules #1 and #2, regarding respect.) - As a group that can interface with other bodies to assist developers in improving FreeBSD. Just putting the core team label on a request often results in the request being expedited. Core should take all reasonable actions to assist developers in their efforts to improve FreeBSD's code, resources, and visibility. Please observe that none of these core team responsibilities involve writing code. The roles of core are managerial, political, and social in nature. People with these skills, as well as a dedication to the FreeBSD Project, should be chosen for the team. Direction for the FreeBSD Project --------- --- --- ------- ------- First of all, the Project is doing just fine. There is no incipient death, no going-down-in-flames, no BSD-is-dying! FreeBSD, viewed objectively, is going quite well. The OS is being used in more places every day; we have all kinds of development efforts occurring, from the total rearchitecting of the kernel to improvements in the release system. FreeBSD has excellent documentation, and nurtures the ports collection, arguably the best third-party application packaging system in common use anywhere. FreeBSD is consistently improving. So, how should core change or set the direction for the Project? It shouldn't. That's the job of the committers as a whole, and it is being done very well so far. Suggested Core Votes --------- ---- ----- As many have said in the mailing lists, and as should be obvious, core functions best when it can work as a team. Whether or not you choose to vote for me, I encourage you to vote for the following people, all of whom have shown the utmost dedication to and respect for the FreeBSD Project, have proven they can work together, and who are, in my opinion, particularly well-suited for the responsibilities of core: - - - - - Contact ------- Communication is a bidirectional activity. I encourage personal email with constructive criticism of my views, suggestions for improving this statement, and questions about my opinions on issues regarding the FreeBSD Project. ---------------------------------------------------------------------- Warner Losh Last modified: May 16 16:07:20 2002 If you know me; like what I've done, and trust me to do what's best for the project, please vote for me. If not, then that's cool too. Core team has been extremely frustrating to me as core.2 never really jelled until almost the end. I hope that whomever is elected to core.3 can form a cohesive group that can work together to solve the various problems that FreeBSD confronts today and in the future. Please consider how well the individuals you vote for will work together as you cast your vote. A good team that works well together is more important than the exact details of how individuals would solve the problems, since no one individual's views will, in the end, be what gets implemented. Also, if you are elected to core.3, be sure to keep Wilko happy. He'll help make you successful. When he retires, be sure to find a good core secretary quickly. ---------------------------------------------------------------------- John Baldwin Last modified: May 15 02:43:03 2002 History: I first became a documentation committer in August of 1999. I did some time closing doc and www PR's before I was sucked into the src side of the tree. (Lesson: keep young doc committers away from Mike Smith if you want to keep them as doc committers.) I worked on the i386 bootstrap for a while before moving over into kernel land and SMPng. I am currently employed full-time by The Weather Channel to basically hack on FreeBSD and as such am possibly more available than other folks. My weaknesses include procrastination and perhaps an over-appreciation of process. For Core:TNG (or would it be DS9 by now?) I think that it's role can basically be summed up as something like this: Core should ensure that an environment exists in which committers can work together to get work done. Note that I don't think core is directly responsible for creating this environment but should instead delegate as appropriate to avoid burning out all its members. The environment should be something that the community really creates and fosters, core should just provide direction and approve new members. I'm still thinking this through though. I do not think that core should set architectural direction. ---------------------------------------------------------------------- J. Mallett Last modified: Jun 25 11:21:18 2002 Well, it's the last day left of voting, so I'm off the soapbox to say something for last minute voters: Vote for the people that you think will be the best possible core team, as a whole, that FreeBSD can make from the available candidates. Don't vote for someone because you like them or you think they are amusing, vote for them because you think they can do something good as core. If you've been a committer for long enough you've probably seen them all involved in flame wars, and you've probably seen how they all work in a group; Simply vote for the people who have proven they have what it takes to be productive core members. Personally, I think that means the following people are also worth looking in to, so if you go read their statements, you might find something you like. But more importantly, think about their past behaviour and their past contributions, and weigh that with that of the other candidates. Be sure to think about whether they can work as a part of a team, too. Benno Rice Warner Losh John Baldwin Mark Murray Mike Barcroft Robert Watson Wes Peters Thanks, and remember, FreeBSD _is_ Fun, if you make it fun! juli. ---------------------------------------------------------------------- Jun Kuriyama Last modified: May 20 00:50:35 2002 I jointed the project as a ports committer in April 1998. In addition to ports related works, I'm also serving as one of the webmasters for http://www.FreeBSD.org/ as well as managing the Japanese documentation team. I'm the youngest member of Japanese core team. Japanese core team is responsible for jp.FreeBSD.org domain, user community and many machines. I'm managing the team actively as well as some important machines at jp.FreeBSD.org. The current state of the core team is not so bad, in my opinion. My belief is that the way the Core Team runs the project should not be put in drastic changes. I just wish to solve each problem and improve the project. As a member of the Core Team, I will listen to many different opinions without my own subjective view, and try to lead fair decisions. Please do not vote for me if you don't think I have that ability. ---------------------------------------------------------------------- Mark Murray Last modified: May 22 21:24:50 2002 I have been a BSD user since 386BSD 0.1 and the patchkits. I got my committer status some time round FreeBSD 2.0, and that was to support the growing crypto movement which was eventually built around internat.freebsd.org. I jokingly describe my politics as "libertarian fascist"; this means that for the most part I believe in letting folks get on with what they want to do (that is the libertarian side). When things get out of hand, I belive in being strong about dealing with that (fascist). We are all here because in some way or other we need to satisfy a passion for FreeBSD. There are 300-odd of us, and consquently 300 differing opinions on how this needs to be achieved. I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricty that the project so badly needs. I'd like to see a return to a system where co-operation is assumed and can be counted on, personal attacks are a thing of the past, and the pointy hat is something that is taken and not given. Discipline is something that I feel is inevitably necessary, but is a last resort not a first, and is something that is doled out with regret and not fervour. Core's job as a sort-of policeman is also necessary, and such actions that it may take should be divorced from discipline and be restricted to that which is necessary to contain a heated issue until it can be dealt with formally. I believe that I have the skills and patience to contribute substantially to achieving the above. I have made mistakes, and I can see from first hand the faults of the dark side. I am resisting a temptation to list a group that I would prefer to serve with, not because selecting that group is difficult, but because selecing those who should NOT be in that group is more difficult. I believe that I could serve with any of the current candidates. If you like, view my non-list of co-candidates as a weakness in my decision ability! ---------------------------------------------------------------------- Makoto Matsushita Last modified: May 30 18:03:10 2002 History/Background: Involved with many jp.FreeBSD.org activities since 1996, including core@jp.FreeBSD.org, postmaster@jp.FreeBSD.org, hostmaster@jp.FreeBSD.org, root@{www,home,daemon,snapshots,ftp4,...}.jp.FreeBSD.org (known as 'the most appeared name of *.jp.FreeBSD.org host administrators'), and daily SNAPSHOTs Project manager (also known as 'snapshots. jp.FreeBSD.org'). FreeBSD committer since October 2001 (src/ports area). Research Associates of Software Engineering Laboratory, Division of Computer Science, Department of Information Science and Technology, Osaka University. Using FreeBSD since 2.0.5-RELEASE. Opinion: IMHO, current FreeBSD projects and committers have fewer respects to others. I don't know why, but it may or may not come from the fact that The Project itself is larger than before; so many people can't understand what each committer is working on, what issues, problems, topics, etc are there. You know that there are lots of issues around coreteam; as a result, it is not too much to say that there are too many unwanted jobs around core. I state my impression about current coreteam as 'going to be a large government.' But I don't think the big coreteam is good for us. Coreteam should be the 'core' of The Project; it should be a small entity, with helps of others. It can't be established only the coreteam's effort -- it is important that each committer changes their mind that coreteam is not a police of our community, and also important that coreteam respects to, and/or is respected by other FreeBSD committers. Coreteam should decide the final answer of all problems of The Project, but ordinary decision making should be delegated to the outer-core, just like portmgr of ports area. According to my past experience of core@jp.FreeBSD.org, small government model can run fine (at least jp.FreeBSD.org inside, which organized by 80 peoples), if all people understand the intention of whole organization structure. Strict rules can be useful, but for me FreeBSD is just a fun so rules are sometimes doesn't match to our goal. Respect others again, and make a good coreteam by *all* committers -- that's my wish, and I believe that this is the only way to make a good Project. Thanks for reading my statement. I hope you'll make a good decision for our Project (no matter you vote me or not). ---------------------------------------------------------------------- Mike Barcroft Last modified: May 15 05:51:22 2002 HISTORY: I've been using computers for almost as long as I can remember. My first UNIX account was on SunOS system, and since that time I've never forgotten how truly fantastic BSD is. I've been a committer for almost a year. For the last 8 months or so, I've been working on FreeBSD's standards conformance [*] (specifically POSIX.1-2001 and C99). I've assembled a small group of exceptional individuals to help progress the project. We are making some significant advances. I don't think it will be too much longer (another year or two) before we're ready to start raising money for UNIX certification. :) FREE TIME: I have a significant amount of free time that I can and do devote to FreeBSD. I am an independent contractor, and have the distinct advantage of being able to choose my hours of paid work. I intentionally work very short days (3-4 hours on average) so that I can spend time on one of my main interests, FreeBSD. OBJECTIVES FOR CORE: I think where the current Core Team has been most successful, has been with setting up small groups of people to oversee specific tasks, such as the release engineering and security officer groups. I'd like to see this trend continue as much as possible. For example, I can forsee an architectural review board to settle technical disputes when a consensus can't be reached through the normal channels. My other main objective, should I be elected to Core, is to reduce red tape and streamline Core operations. I think this is best achieved through a cooperative spirit and non-contrarian agenda. In particular, I don't feel it's appropriate to nitpick everything to death. That type of behaviour just isn't conducive to a health project. To conclude, if you are looking for a team player who's pretty easy to get along with and has FreeBSD's interests at heart, I'm your candidate. [*] http://www.FreeBSD.org/projects/c99/ ---------------------------------------------------------------------- Murray Stokely Last modified: May 15 17:51:16 2002 Bio: I have been involved full-time in the FreeBSD Project for the past 3 years. Over the past 12 months I have been an active 'src' committer, as well as the single most active committer to 'doc/' and 'www/' as measured by : http://people.freebsd.org/~peter/commits.html I have been involved in the productization of FreeBSD since I joined Walnut Creek CDROM in 1997. I have worked hard to document the release engineering process ever since Jordan first asked me to help out with the release engineering team last year. I have written a 10 page paper on the subject, maintained release schedules, and with the help of the rest of the RE team I have released several versions of FreeBSD 4.X as well as FreeBSD 5.0 Developer Preview #1. I have also worked hard to increase our visibility on the retail shelves of U.S. computer stores such as Fry's and CompUSA. I have done this by spending 6 months working as editor of the 2nd Edition FreeBSD Handbook, working on product copy for FreeBSD retail boxes, speaking about FreeBSD at store promotional events, etc.. For most of my employment with Walnut Creek CDROM and BSDi, my title was simply "Project Manager" and I believe that my goal-oriented professional skills would be an asset to the new core team. I continue to be employed full-time to work on FreeBSD, and my work on FreeBSD-core would be part of my "day job" giving me the freedom to spend the time required of a commitment to FreeBSD-core. http://www.FreeBSD.org/releng http://www.FreeBSDmall.com ---------------------------------------------------------------------- Nick Sayer Last modified: May 20 00:55:27 2002 This statement is also available at http://people.freebsd.org/~nsayer/core.html I've been a user of FreeBSD since version 1.1.5.1, and I've been a committer since March of '99. I believe I have this to offer: Neutrality: I do not have an agenda or an axe to grind. I have not been a party to any disputes that have been elevated to core. Independence: My employer is not involved in FreeBSD in any way. Service: I am ready, willing and able to serve, and can forsee no circumstance that will hinder my ability to do so. Energy: I am not deeply involved with any projects that would distract me from my duties as a member of core. I believe core members can serve the project best by being core members first. I fully admit that I am not the project's most active committer (by the same token, however, I am not the project's least active committer either). Mostly this has been because my real job has required 80 hour weeks from me for the last 4 months (things are a lot more calm now, however). The good thing about this is that it means I have the time to dedicate to being a core member. I believe this is an important thing to consider when selecting a core team. A couple of questions have come up in the developer's list on which I'd like to offer my opinion: 1. How would you fix core? I don't believe there is very much wrong with core at all. core needs to delegate more, and I have seen the first steps at implementating more delegation even now, before the election has taken place. 2. If nothing is wrong with core, what's all the fuss? I think that the current core team did a pretty good job, especially considering they were the first inhabitants of an office newly created. I think as soon as they sat down in that new office a collection of picketers took up residence outside ready to criticize everything core did. 3. So why do you want the job? As I have said elsewhere in my statement, I think at least part of the reason that core has had trouble is that core members did not have enough time available to dedicate to the position, and that they didn't delegate enough responsibility to others. In moving towards a balance, I am offering to make core my primary contribution to FreeBSD. I think everyone who wants to be in core should do that, otherwise they'll be too distracted to function. 4. With whom else would you want to serve on core? I am ready and willing to serve with anyone. I have nothing to say about any of the candidates I could not say about all of them. Remember, folks, it's all about the software. The committers make the software. core exists simply to facilitate the work. Thank you for your time and attention. Nick Sayer ---------------------------------------------------------------------- Paul Richards Last modified: May 17 19:19:44 2002 I believe the following are the key issues for the next core team. 1) Core should be more open and take more notice of the committers. There is no reason why there cannot be more open debate about issues. While core members are ultimately the people that get to make the decisions, there's no reason that committers should not be able to see the full reasoning behind those decisions. I think the core list should be read only to all developers, with only a small number of topics restricted when absolutely necessary. Core discussions and decisions should focus on the strategic issues of the project and there is no reason for those discussions to take place behind closed doors. Core should also spend more time listening to committers. The core members are representatives of the committers and not a law unto themselves. It's impractical to organise a vote and have discussions of all committers for all issues, so we need a core team, but that does not detach them from the rest of the project. At the end of the day the core team should be responsible for digesting the views of the project as a whole and organising matters *on their behalf* so that the project can move in the direction it feels it wants to. 2) There should be a minimal, but formally sound set of rules. We don't want lots of rules and regulations, but at the size we are now there needs to be a framework for controlling events; anarchy will not produce the FreeBSD that we want to see when there are this many committers. There don't have to be pages of rules to make things work. The key is to have a small number of well thought out, unambiguous procedures so that everyone knows and undertands how things are expected to happen. 3) Core members should have management skills. This does not mean that the project needs to be overly managed, but it does mean that what management is needed should be done by people who have that sort of experience. Core members need to be people who are willing and fully expect to give up a large part of their time to deal with the "paperwork" of the project. I do not believe in appointing a secretary from outside of core. My opinion is that this is exactly the sort of work core members should be expected to do and that such a position should come from within core itself. It is the sort of task that I would expect to have to do if elected as a core member. 4) Core should delegate tasks to the most appropriate people. If core is made up of management type people then it *must* delegate other tasks to people better qualified to do the job e.g., we should have various teams dealing with the day to day issues of docs, ports, src etc. We need organisers to deal with the management of the project, but we don't need managers to get in the way of the hackers who want to do the coding. There should be an architectural board for determining the technical merit when there are deadlocks amongst developers, and there should be a disciplinary committee for dealing with bad behaviour in the project. Core members are not the right people to deal with all these diverse issues, core should focus on the bigger issues and not all the day to day detail. They should oversee the running of the teams so that there is some focus to the direction of the project. As a core member the above 4 points would be the guiding principles in my approach to running the project. Core needs to be pro-active in fixing problems before they arise. When necessary, it must deal with situations with a firm hand, and not avoid its responsibilities, but on the whole it should create an environment that's fun to work in so that conflict and animosity do not arise in the first place. I believe I have a proven track record of succesfully organising and running teams. As well as running FreeBSD Services Ltd I also lobbied hard last year to establish BSDCon Europe in the European community and for my efforts I became the conference chair. However, an event of that complexity would not have been possible without putting together a solid team and keeping it motivated. It was organised and run entirely by a team of volunteers and I believe that proves the point that volunteers, when motivated by the outcome, are willing to do whatever is necessary, even when it's not all fun, to achieve a desired goal. The most satisfying feature of the conference, for me, was the great sense of community that we created. Through working together to achieve something we all believed in we had a lot of fun. I believe that I can bring that experience into the core team and help to keep the project a fun place in which to do exciting and innovative things. ---------------------------------------------------------------------- Peter Wemm Last modified: May 17 05:21:53 2002 I generally dislike politics, so I'll try and keep this short and to the point. Brevity is priceless and something that we are sadly lacking these days. I've been directly involved with FreeBSD since about 1995. I've seen the highlights and a lot of bad stuff that should have been handled better. Lately I've been rather concerned about the sheer volume of politics, noise, excessive bikeshedding over the most minor things (while not being able to get feedback on the important stuff due to the noise) and so on. I think core's "hands off" approach last time was a mistake and things went off into the weeds too often and core was too dysfunctional to reign it in before it was too late. [It was too busy drowning itself with internal red tape and tunnel vision.] This time I believe core should be more active in keeping things focused and on track, either directly or by (preferably) delegating more to the right people for the job. Specifically, this includes things like an arch group, an advocacy group, maybe even a committer recruitment/approval group etc. This time core did some delegation last time which was mostly successful. But, it did not delegate enough and core remained a bottleneck and burned out folks. FreeBSD is supposed to be fun. FreeBSD is supposed to be about doing it right. Sometimes it seems that we have lost sight of that in the noise. ---------------------------------------------------------------------- Ollivier Robert Last modified: May 20 18:20:16 2002 History: I started using 386BSD in 1993, got onto the FreeBSD waggon since the beginning and became a committer in 1995, just after FreeBSD 2.0, initially as the FAQ maintainer (SGML usage in FreeBSD is partly my fault :-)). Since then, I've been dealing with user-land issues (ntpd mostly), used to play a bit with the kernel and VFS subsystem and also some ports committing. Background: I'm in my middle 30's with a lots of computer experience (I started in '81) and heavy UNIX usage as system administrator since '88-'89. I think, like many, that core should take a more active participation and try to help avoiding bikesheds and endless discussions (not to mention flame/commit wars) in order to keep people focused on our goals and I, as a rather diplomatic guy, can -- I hope -- help in this. It means showing that core is ready to stand between people when there's a problem, even applying the stick if needs be. Conflict resolution is unfortunately where we need improvement. We need to prevent conflicts but also to solve them. Core doesn't need to do everything of course and delegation needs to be kept as a goal. I see that as a new experience and a new way to contribute to FreeBSD. I can work with anyone but I think these are also good candidates: Mark Murray Jeroen Ruigrok van der Werven Peter Wemm John Baldwin Greg Lehey Robert Watson ---------------------------------------------------------------------- Robert Watson Last modified: May 19 21:13:06 2002 Background: Research Scientist (DARPA Principal Investigator), NAI Labs; FreeBSD Core Team Member, Committer, member of Release Engineering, Security Officer, Donation Liaison teams; Founder, TrustedBSD Project. Since joining the FreeBSD Project two and a half years ago, I have contributed to the project in both development and administrative roles. Professionally, I have worked to direct substantial funding and staffing for new FreeBSD-based research and development funded by DARPA, supporting new features such as the TCP SYN Cache, UFS2, GEOM, the TrustedBSD Project, OpenPAM, as well as sponsoring and organizing more general project activities including the FreeBSD Developer Summit at BSDCon, and the upcoming Summit at USENIX ATC. Of course, my involvement in the FreeBSD Project is not limited to that mandated by my job :-). I have worked hard to promote FreeBSD inside and outside the open source community, building links with other projects, encouraging adoption of FreeBSD and FreeBSD-derived technologies in research, educational, commercial, and government settings. I believe that the FreeBSD Project provides a unique blend of advanced research and software development, and the opportunity to provide a high quality production operating system used widely through industry. Allowing this tradition to continue is extremely important to me, and I will act to promote development and use of FreeBSD whatever role I may play in the project. Direction: One of the fundamental tenets of the FreeBSD Project is its centralized and cooperative development model. The FreeBSD Core Team is responsible for making sure that the environment of the Project is such that this model can remain central to the Project. If given the opportunity to continue to serve on the FreeBSD Core Team, I will continue to work towards this goal. In my current term on the Core Team, I've worked to improve communication throughout the project by serving on a variety of our task-oriented sub-projects, as well as coordinating routine development status reports to maintain a broader understanding of the direction of the project. Likewise, I have attempted to play a role in conflict resolution within the project: conflicting opinions are inevitable in any large group project, and the FreeBSD Project is no exception. While the project is based around a technical goal, the social process by which that goal is accomplished is vital to the identity of the project, and to its success towards its technical objectives. This means that the Core Team needs to act decisively, as well as carefully. Our notion of what the FreeBSD Core Team should be is clearly evolving still, but I believe my background and skills make me highly qualified to play a central role in it. Recommendations on voting: the core team should be selected based on individual traits, but also on their ability to work effectively and efficiently as a team. For a delegation-centric model to work, the team as a whole must have a high level of trust in all the individuals on the team, or risk group review of every detail by the team as a whole. Likewise, for the new core team to have credibility in a conflict resolution role, it should be made up of individuals who have demonstrated strong past experience in a conflict resolution role. I would recommend voting for core team members based on their past demonstrated skill at working closely with others to accomplish both technical and non-technical goals. This doesn't mean the core team can't have diverse experience and opinions, just that when necessary, they need to be able to act as a group without high levels of friction. ---------------------------------------------------------------------- Scott Long Last modified: May 28 01:43:23 2002 My history: I've been using and promoting BSD since 386BSD 0.1, back in late 1992, and received my commit bit in September of 2000. I maintain the aac driver and the udf filesystem, and have contributed to things like usb, acpi, and cam. I do systems and driver programming for Adaptec; previously I was in the US Navy. Statement: FreeBSD has always stood for 'doing it the right way'. It's part of the BSD tradition, and it's what sets us apart from Linux. The core team needs to ensure that that philosophy remains, while balancing the 'hacker' desire with the commercial needs of the project. As others have said, please vote for people whom you think will benefit the project the most. The partial list of people whom I'd like to see on core is: Robert Watson - By far the best leader type that the project has seen in a long time. Jeroen Ruigrok - Very level headed and insighful. Also a natural leader. Warner Losh - Has been a good spokesman for the current core, and is very level-headed. Michael Lucas - Yeah, he's not running, but he should be =-) Ade Lovett - Dammit! He was running, but not any more... ---------------------------------------------------------------------- Wes Peters Last modified: May 20 07:01:34 2002 History: I have been a UNIX programmer since 1981 and a FreeBSD programmer since just before 1.0. I have used FreeBSD almost exclusively on my personal computers since then, and in a professional capacity as much as possible since then. I became a committer in 1998, and remain a middle of the pack committer in the src, doc, and ports trees. I spent a year and half answering on the -questions mailing list before becoming a committer. I am also one of the founders of the Daemon News ezine, and have co- authored (with Greg Lehey) a column every other month since 1998. I participated in the advocacy mailing list for several years and helped write the bylaws and election rules we used to elect the current sitting core team. I am currently a member of the security officer team, contributing as time allows. Background: 40 years old, happily married, father of one daughter. Professionally I am a Senior Engineer for NextGig, Inc., where I am charged with kernel support and optimization on FreeBSD x86 and Linux PowerPC platforms. (Yes, Benno, I'd love to replace Linux with FreeBSD/PPC.) I have been a team lead, manager, and manager of research and development, managing programmers for more than ten years and permeate every group I lead with an air of work hard, play hard, and leave a legacy of outstanding work. Standing because: I want FreeBSD to continue to grow, and to provide as much enjoyment to future legions of programmers as I have found. o I can work with anyone who is honest and is working for FreeBSD and the committers community, whether I agree with them or not. My position is not the only possible viewpoint and I am human and fallible. I welcome the opportunity to work with anyone who has similar goals and sense of community. o I will help to more carefully define the role of core so everyone will know what to expect of them and when to expect it. This will also define what core should NOT be expected to do. Developers working on shared code must learn to work together or be prevented from messing up the FreeBSD code base. This is the primary function of the core team: deciding who can and who cannot commit changes to FreeBSD. Individuals who cannot work in teams and cannot find areas to work on alone must be dismissed for the overall good of the project, regardless of their talents. The one talent we absolutely require is the ability to work in a team. This is different from the early days of FreeBSD, where there were large sections of the system that had only one developer. Now we have large numbers of developers working all over the system who must coordinate their work with others. If this is somehow less fun than the early days, it is the price we have to pay for being successful in recruiting so many developers. o I will push the core team to be more open. Rather than making all core communication secret by default, I would like to see it available to all committers unless someone on core explicitly designates it private. When the messages themselves are marked private, the subject lines and authors should still be available for review by committers. o I will help charter and populate other teams to shoulder the work that has not gotten done in the past. The Security Officer, Ports Manager, and Release Engineering teams have recently showed us this is the way to fix manpower problems and we can apply this to other problem areas. o I will recruit a team of mediators to help in conflict resolution. This team will be tasked with finding an affordable (preferably free) training course in mediation skills and develop a charter for conflict resolution in FreeBSD. They will then assist in settling disputes as needed, finally making a recommendation to the core team if mediation fails. I have been involved in volunteer organizations much bigger than FreeBSD, including one that settles nearly as many disputes per year as the US court system (USSailing). Their mediation program works quite well and ours can work as well if we're willing to follow it. I think this is an excellent role for some of the core team alumni, if they are willing. Both disputees must agree on the mediator in order for mediation to work; the mediators will have to be known and trusted members of the FreeBSD community who can be fair and unbiased. o I will also push us in the direction of recognizing and using the talents of everyone who wants to contribute to FreeBSD, with whatever skills they have. This includes programmers, managers, writers, artists, web designers, musicians, psychologists, and anyone else who wants to contribute to FreeBSD. We can probably even find a place for lawyers to contribute if we can find any. As for that squabbling and yelling, the "vocal minority" here don't hold a candle to a 6 year old howling because she accidentally ripped Barbie's head off; I am not likely to be swayed by a few heated email exchanges. ----------------------------------------------------------------------