Slashdot Mirror
New FreeBSD Core Team Elected
BSD-Pat writes "A new FreeBSD core team has been elected for the first time in the project's history. The BSDToday article can be found here.
I'm personally excited that this seems to open up the playing field for developers to get involved on a deeper level with FreeBSD and choose the direction to take for the future." Update: 10/14 01:44 PM by H :BSD-Pat sent an update saying that the story was actually broken by Daily Daemon News.
Of course, this assertion has already been disproven at Segfault, not once, but twice. ;-)
--
--
We have fought the AC's, and they have won.
Hi again Bruce,
Feel free to reject the statement that any number of people are "allowed to modify a Free Software product, either Linux or a BSD". I didn't say anything about the restrictions regarding the modifications of copies of the source code that is distributed in the official projects.
There are two possible meanings of (for example) "FreeBSD source code", depending on stress:
The _FreeBSD_ source code is "The source code to the FreeBSD operating system, that is used to generate FreeBSD install CDs, is available in the FreeBSD cvs tree". In this case, no, you can't modify the _FreeBSD_ source code, because you don't have commit privilege - the 233 committers in FreeBSD can, though.
Or, the FreeBSD _source_code_ is "The source code to the FreeBSD operating system, freely available for anyone to use, whose modification need not occur in the active FreeBSD project, and can indeed be used in other projects". In this case, you're totally free to modify the source code. However, you are not modifying the source code to the actual FreeBSD operating system, just a local copy. You can feel free to submit patches back if you like.
The same applies to Linux - you can play all you like with the code with the usual restrictions, but you need to get Linus to accept it if you want it to become part of the Linux kernel. You can modify your own copies of it, but you need his permission and intercession for you to indirectly modify the actual Linux kernel source code, as distributed in tarballs.
I can't believe you're talking about the second meaning, since it's obvious I'm not talking about it in my comment - I specifically talk about direct modification of the FreeBSD source in CVS, and the modification of the Linux kernel in the tarballs.
In the first case, and as you later continue, the core team or Linus do indeed have no way to compel people to make changes to the "offical" distribution formats of FreeBSD (cvs) or Linux (tarball), nor do they have any power to compel people not to make their changes in other formats, such as local copies or other projects (subject to licensing).
The thing is - if everyone disagreed with Linus, would it still be Linux? Linux is a registered trademark of Linus, and as such, if people run off and do other work, it is not the "official" Linux tarball, and it would need to be renamed, unless Linus gave his approval.
I'm not sure if Mr. Jolitz trademarked 386BSD, but he certainly would not have allowed the upstart NetBSD and FreeBSD teams to continue calling themselves "386BSD" - that was his baby. Hence the renaming. FreeBSD is a registered trademark too, so if the FreeBSD core (who hold it with permission of the trademark owner) were deemed too slow or old or whatever to do real work, the disillusioned could form another system, but not "FreeBSD".
I'm pretty sure you know all this, I just wanted for the slashdot readers to know that you were talking about something unrelated to my comment; your comment mostly discusses the advantages of open source development (freely available, or free-for-source-available-derivatives source) and the realities of open source projects (the inability to force cats^H^H^H^Hhackers to follow a given path).
Cheers,
Neil
Hi Bruce,
Obviously "gets hit by a bus" is a metaphor, and it is not to be taken seriously. It means "becomes unavailable", and I think you'd agree that if Linus did become unavailable, there'd be quite a bit of upheaval. Nothing fatal I imagine, but some upheaval - whoever takes over would also probably get quite a bit of "But Linus would have done this..." coming his or her way.
However, if one of the FreeBSD Core "became unavailable" because of other work, a change in direction, moving to another project, it wouldn't have nearly the effect. I imagine the most likely to cause the most upheaval is jkh. Whoever replaces the core member isn't likely to face "but foo would have done this..." arguments - core is about reaching concensus on issues that have escalated to that level - to settle disputes, add more committers, and very very occasionally decide policy. Everything else is based on rough concensus and working code in the project.
I don't believe you can say that the Linux kernel development is "at least as decentralized", in the sense that at least 233 people can directly modify the FreeBSD source code, including kernel. There is no need for them to get formal review and acceptance by a single person before it is possibly to go in - it is simply expected that review is sought, that the code is tested, and that you know what you're doing, and that you notify the maintainers or active worker on the subsystem you're working with. Architectural changes are monitored by various people (as I imagine it is with Linux too), and any questionable code is (optionally) backed out and discussed. People who repeatedly refuse to get review and discuss changes would theoretically get their bits removed, but there hasn't been a case in the time I've been following the project.
This is "decentralized", meaning ``withdrawn from a center or place of concentration; especially having power or function dispersed from a central to local authorities''. I'm not saying it's good or bad, but that's what it means - all changes are centralized through a point of concentration (Linus at the moment). The function of physically changing the code and generating the tarballs or whatever (since there's no versioning) falls with him.
One could theoretically extend that to FreeBSD in the fact that changes have to be made via cvs (or locally with cvs) on the FreeBSD cvs server, but that's a little technical. The function of changing the code is performed by the committers - the rest is automated and not concentrated through a single reviewer and changer.
Again, this is not a judgement, simply an observation. I don't think anyone in FreeBSD has the time and inclination to step up and manage every single change to the kernel, userland, documentation, or web site, so the functionally-decentralized distributed method probably suits FreeBSD.
Neil