3 ms·

> Giving money to the Foundation with 'bad intent' has no influence on the FreeBSD Project Maybe in theory, but that sounds very doubtful in reality. I'm sure

> Giving money to the Foundation with 'bad intent' has no influence on the FreeBSD Project Maybe in theory, but that sounds very doubtful in reality. I'm sure the people who run the project know well what is going on in the Foundation, and know where their critical resources - including money - are coming from. Also, to be clear, I'm raising the issue more generally; this isn't about the FreeBSD project in particular.

tachion 10y ago
Sure, the foundation could hire RedHat to write systemd port for FreeBSD, but no matter how much they'd pay for it, no matter who would write the code, FreeBSD is a community driven open source software, and such code submission would undergo the same code review process and, most likely, loud protest by all other members of the project, all of who have commit bits to stop/revert any shady practices. So, we'll be happy for you to donate your money to the foundation, the more the better, but we can't promise you'll get what you've paid for ;)
- hackuser 10y ago
  It would be interesting to learn how the FreeBSD code submission and review process works. Even in FOSS, very few people actually review the code and I'm confident that top maintainers could find a way to include or exclude something if they wanted to - they know the system, process and people far better than anyone else, and have great influence over all of it. For example, OpenBSD excluded virtualization for a long time. I don't at all think it was something nefarious, but if Theo de Raadt had wanted to block virtualization for some ulterior reason then very few people would have the ability to detect his motive and the ones who could are strongly influenced by him.
  - emaste 10y ago
    In FreeBSD we have a long history of including metadata in commit messages (bug reference, sponsorship information, reviewer list), and introduced Phabricator for code reviews a while ago. So you can easily find Foundation-sponsored commits and for many of them observe the review history. If using the git mirror a command like git log --since=2016-01-01 --grep 'Sponsored by.*FreeBSD Foundation' will show the Foundation-sponsored commits in 2016. Here are a few recent examples: r310702 btxldr: process all PT_LOAD segments, not just the first two https://reviews.freebsd.org/D8929 https://reviews.freebsd.org/D8929 This was a tiny change of mine, removing an 18 year old assumption to allow us to build the FreeBSD base system with LLVM's LLD linker. Reviewed by a Foundation employee and a FreeBSD (and Illumos) community member. r310617 Make knote KN_INFLUX state counted https://reviews.freebsd.org/D8898 https://reviews.freebsd.org/D8898 Reviewed by a FreeBSD developer working at Isilon. r310371 bhnd: remove srand() to ensure deterministic output https://reviews.freebsd.org/D8857 https://reviews.freebsd.org/D8857 Another one of mine as part of the Reproducible Builds effort. Reviewed by the original author of the affected driver. These are small, uncontroversial fixes, but demonstrate the approach the Foundation strives to take with all development work. Also being able to drive longer-term projects and maintain subsystems over long timescales is a significant advantage of having funded developers on staff. r310154 Add support to read the _CLS entry if it's present https://reviews.freebsd.org/D8721 https://reviews.freebsd.org/D8721 A commit from a Foundation project grant recipient, part of adding ACPI support along with the FreeBSD/arm64 porting effort. Reviewed by a long-time FreeBSD committer and core team member. The Foundation drove the overall arm64 porting effort. Cavium (an ARM CPU licensee) and ARM helped contribute to the initial porting effort, which was generally reviewed with a similar approach. r301172 Import NetBSD's blacklist source from vendor tree https://reviews.freebsd.org/D5912 https://reviews.freebsd.org/D5912 The Foundation provided a grant to port NetBSD's blacklistd daemon to FreeBSD. The initial work here was reviewed by an idependent, long-time FreeBSD committer. The Foundation's development projects have no special status - work is still subject to the communities norms and standards. If there were to be a dispute over a proposed project or change the final authority rests with the elected core team. (The current core team includes some Foundation members, but a minority position.)

tachion 10y ago

Sure, the foundation could hire RedHat to write systemd port for FreeBSD, but no matter how much they'd pay for it, no matter who would write the code, FreeBSD is a community driven open source software, and such code submission would undergo the same code review process and, most likely, loud protest by all other members of the project, all of who have commit bits to stop/revert any shady practices. So, we'll be happy for you to donate your money to the foundation, the more the better, but we can't promise you'll get what you've paid for ;)

hackuser 10y ago
It would be interesting to learn how the FreeBSD code submission and review process works. Even in FOSS, very few people actually review the code and I'm confident that top maintainers could find a way to include or exclude something if they wanted to - they know the system, process and people far better than anyone else, and have great influence over all of it. For example, OpenBSD excluded virtualization for a long time. I don't at all think it was something nefarious, but if Theo de Raadt had wanted to block virtualization for some ulterior reason then very few people would have the ability to detect his motive and the ones who could are strongly influenced by him.
- emaste 10y ago
  In FreeBSD we have a long history of including metadata in commit messages (bug reference, sponsorship information, reviewer list), and introduced Phabricator for code reviews a while ago. So you can easily find Foundation-sponsored commits and for many of them observe the review history. If using the git mirror a command like git log --since=2016-01-01 --grep 'Sponsored by.*FreeBSD Foundation' will show the Foundation-sponsored commits in 2016. Here are a few recent examples: r310702 btxldr: process all PT_LOAD segments, not just the first two https://reviews.freebsd.org/D8929 https://reviews.freebsd.org/D8929 This was a tiny change of mine, removing an 18 year old assumption to allow us to build the FreeBSD base system with LLVM's LLD linker. Reviewed by a Foundation employee and a FreeBSD (and Illumos) community member. r310617 Make knote KN_INFLUX state counted https://reviews.freebsd.org/D8898 https://reviews.freebsd.org/D8898 Reviewed by a FreeBSD developer working at Isilon. r310371 bhnd: remove srand() to ensure deterministic output https://reviews.freebsd.org/D8857 https://reviews.freebsd.org/D8857 Another one of mine as part of the Reproducible Builds effort. Reviewed by the original author of the affected driver. These are small, uncontroversial fixes, but demonstrate the approach the Foundation strives to take with all development work. Also being able to drive longer-term projects and maintain subsystems over long timescales is a significant advantage of having funded developers on staff. r310154 Add support to read the _CLS entry if it's present https://reviews.freebsd.org/D8721 https://reviews.freebsd.org/D8721 A commit from a Foundation project grant recipient, part of adding ACPI support along with the FreeBSD/arm64 porting effort. Reviewed by a long-time FreeBSD committer and core team member. The Foundation drove the overall arm64 porting effort. Cavium (an ARM CPU licensee) and ARM helped contribute to the initial porting effort, which was generally reviewed with a similar approach. r301172 Import NetBSD's blacklist source from vendor tree https://reviews.freebsd.org/D5912 https://reviews.freebsd.org/D5912 The Foundation provided a grant to port NetBSD's blacklistd daemon to FreeBSD. The initial work here was reviewed by an idependent, long-time FreeBSD committer. The Foundation's development projects have no special status - work is still subject to the communities norms and standards. If there were to be a dispute over a proposed project or change the final authority rests with the elected core team. (The current core team includes some Foundation members, but a minority position.)