Re: Bazaaring the cathedral (Lowering the Barrier to Entry)

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 _at_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_at_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_at_ 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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>