Date: Thu, 2 Apr 2015 08:20:57 -0700 From: Samuel Cassiba <sam@cassiba.com> To: Eitan Adler <lists@eitanadler.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) Message-ID: <CAOqvHK9uE_LpwpH4W%2B-RskBd2y5yCfs-wmS8YJDvjZRWUCZ-cA@mail.gmail.com> In-Reply-To: <CAF6rxgk0GR6pj2hTQyHWPiu3c_9NyVb-JzOqPgYhWHW6QQqtmA@mail.gmail.com> References: <CAF6rxgk0GR6pj2hTQyHWPiu3c_9NyVb-JzOqPgYhWHW6QQqtmA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eitan, This being posted on April 1 sets off my BS-o-meter, but I'll bite since it's a topic worth shaving a yak or two over. WARNING: there be perceptions and opinions here Having been ephemerally associated with FreeBSD since early 4.x, I never really saw FreeBSD as being cathedral-like, but the barrier to entry today feels even higher than it did 15 years ago. I view FreeBSD as being very much bazaar-like in terms of the actual code that comprises the OS and how it's treated, but like I must reiterate: the wall is harder to scale today. I appreciate the work that everyone has done over the years to bring the project's infrastructure up to modern times, such as the work done bringing in CI, a modern bug tracker and an honest to goodness code review tool, but the general workflow that I learned all those years ago for getting a change to go live *feels* more or less still the same: - find/fix bug - send-pr (okay... but you get the idea) - pester a committer with the proper access - ??? - profit!!! The arbitrary nature of how commit bits have historically been allocated have been more of a detractor than anything, making the the barrier appear even higher than it may actually be. The general wisdom I learned was "when you've bugged people often enough to commit your code, they'll burden you with that ability", which is great in terms of a pure meritocracy, but we're people and things aren't so black and white. Commit access thresholds shouldn't be measured in SLOC. Yes, the meritocratic way of handling commit access has worked well enough so far, but it has been at a cost (see FreeBSD's standing in the mindshare/overall market, as well as number of active FreeBSD committers vs your favorite big name Linux flavor). Access to the tools that the project has gravitated towards can be difficult if not impossible to obtain without a long slog through commit hell to get that sweet @FreeBSD.org spiff. Is a "free commit access for anyone!" approach really the answer? It feels like going from one extreme to the other, and we all know how extremes work. I feel that commit access should be more transparent, so that if someone really wants to be able to push code or act as a representative of the project, they can learn how to work towards that, instead of some nebulous "push enough code until we get tired of committing it". Again, I'm pretty sure this is just a April 1 troll, but it's all worth saying since the topic was brought up. Lowering the barrier to entry is good, but the act of doing so mustn't come at a detriment to quality. -Samuel On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler <lists@eitanadler.com> wrote: > Hi all, > > FreeBSD today has a significant problem of attracting new developers. > The lack of new developers manifests itself in a dearth of driver > support, inadequate documentation, and trailing third party packages. > > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), FreeBSD uses self-hosted subversion. > The use of git goes beyond just the choice of version control. It > allows for workflows that FreeBSD can't even dream of. The linux > kernel has no concept of a committer. Instead anyone can clone the > git tree, build a kernel, and call themselves a Linux distribution. > > Our wiki and code review tools are in an even worse position than our > repository. In order to contribute you need to send an email to > clusteradm@ and hope they deem you worthy enough of access. The bug > tracking system is in a better shape but isn't perfect: while any user > can create an account, their privileges are limited: they can't help > close out bad PRs, reclassify good ones, or do other generally useful > work. > > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. > > This will allow us to quickly gain large number of contributors, who > will be able to make better progress on our missing features, and > rectify some of the drawbacks listed above. > > Today I hope we turn ourselves from the cathedral into a truly open > and democratic project! > > > -- > Eitan Adler > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOqvHK9uE_LpwpH4W%2B-RskBd2y5yCfs-wmS8YJDvjZRWUCZ-cA>