Joke or not, it's worth pointing out that while DragonFlyBSD's approach
seems to be a fairly sane hybrid; there is no reason this can't be done
within FreeBSD right now.

Anyone can clone, but if you can't commit to the repo then you're asked to
register at and send your patch over email.

DFBSD's GItub repo is just a mirror and FreeBSD has something similar
available, including a "GitWorkFlow" document:

So I don't see why *now* someone couldn't basically follow the same
workflow if they wanted to contribute to FreeBSD; namely:

* clone mirrored repo/branch from GH
* make changes
* create a problem report at
* submit patches

And if this is not possible, it is likely a procedural impediment and not a
technical one.


On Thu, Apr 2, 2015 at 10:20 AM, Samuel Cassiba <> wrote:

> 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 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 <> 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 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
> > _______________________________________________
> > mailing list
> >
> > To unsubscribe, send any mail to "
> >
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to