Hacker News new | ask | show | jobs
by jeamland 3426 days ago
Hi. OP (original presenter?) here.

The whole idea of this talk was about the community side of the project. I make exactly the points you're making regarding code size but that just speaks to the difficulty of managing a community looking after a codebase of that size.

I'm also not criticizing the pace of FreeBSD development so much as I'm criticizing the pace of its leadership (of which I'm a member, don't forget) to deal with issues that would make FreeBSD more fun to work on.

1 comments

Thank you for taking the time to reply. It was just a bit of a surprising read from my point of view, as somebody who's not directly involved in the project (like you are) but who's been observing it since around ~2004.

There are three main points in this article: the issue of version control, the "Dragonfly BSD incident", and the GamerGate garbage fire.

Regarding the first issue, while it was sad to see a good dev like Matthew Dillon leave the project, what do you think should have been done better by the leaders of the project? Clearly there was an incompatibility here, maybe having Dillon work on his own project (and then sometimes have a back and forth between Dragonfly and FreeBSD) was the right solution? Would Linux for instance have dealt with the issue better? I recall many personality clashes amongst the Linux "elite", some not so long ago.

The migration away from CVS sure did take a long time, but as you mention yourself the technical challenge was pretty high. Lest we forget, Linus ended up writing his own version control system because the existing solution were not deemed satisfying. And FreeBSD is significantly bigger than linux's codebase. Regarding the test suite, testing operating systems is notoriously difficult (you can't easily abstract away from the hardware to run well contained unit tests). I don't recall Linux having an extensive test suite either.

The GamerGate thing I won't touch with a hundred kilometer pole. How an operating system project got dragged into that I still can't fathom.

So in the end, I don't think those issues are that big of a deal on their own. IMHO the main "trouble" with FreeBSD is simply that its market share is tiny compared to Linux. I'm a big fan of FreeBSD but my IRL job is linux kernel dev, not FreeBSD kernel dev. More and more first party vendors support linux, not any of the *BSDs. "Netcraft confirms it - BSD is dying". There's a momentum problem and I'm not sure switching to github or adding a test suite are going to solve it.

FreeBSD is betamax, linux is VHS. FreeBSD is mercurial, linux is git.

That being said, I don't have a solution either.

The only thing that could've been done better was realizing that there wasn't a way to fix it earlier. The story was more told as to give an idea of the kinds of things a community can face.

The migration to Subversion was given as a case where core could've made a decision and given direction but chose not to. Whether they're right or not is a whole separate set of arguments.

I think everyone would be happier if Gamergate had never been a thing.

The trouble with FreeBSD, as stated, is that like a whole lot of other community projects it's largely volunteer and its leadership is 100% volunteer. If we had more mindshare we might have more volunteers but then we'd need leadership to be more active.

FreeBSD is pretty common in some market segments, especially infrastructure appliances and devices. It's an easy choice for NAS controllers, internet core routers, email gateways, firewalls, messaging platforms, CDNs. Not to forget the humongous chunk of FreeBSD that is in OSX.

If you think it has a small market share, you're looking at the wrong market.

While I agree it is popular in certain circles that use it in high volume, it clearly has a relatively small mindshare among developers and open source contributions. Linux, just the kernel, regularly gets contributions from 100x the people that contribute to FreeBSD base.
I'm gonna have to challenge you on that 100x number because I think you may have plucked it from thin air. Obviously contributor numbers are a) hard to define and b) hard to capture, but for an order-of-magnitude estimation, I give you two sources, both of which have incentive and access to maximise the number counted:

1. Linux. "Over 13,500 developers", https://www.linuxfoundation.org/announcements/linux-foundati...

2. FreeBSD. I make this a little over 2,300 names: https://www.freebsd.org/doc/en/articles/contributors/article...

So I suggest it is a only a 6x difference, or at least in that vicinity.

I imagine that the column inches go overwhelmingly to Linux, but tech journalists are moths to a flame.

https://lwn.net/Articles/708266/ -- 1,719 in a ~ten week window.

https://svnweb.freebsd.org/base/head/ -- 128 individual developers have committed to FreeBSD head in the last ~ten week window. (svn log http://svn.freebsd.org/base/head |egrep '^r[0-9]{6,6} \| ' | grep -B999999999 2016-11-25 | cut -d" " -f3 commits.log |sort | uniq | wc -l)

So Linux has more like 13x individual developer count in recent times. You can round that down to 10x if you like, but 6x doesn't tell the recent story.

Note that this is comparing the Linux kernel to FreeBSD base, which is like kernel + glibc + coreutils + binutils + other stuff.

Mindshare is not a zero-sum game like market share, so scope of function is irrelevant; and is not a short-term phenomenon, so ten weeks is nothing.