5 ms·

I've always thought that often the best way to give is anonymously and I understand I'm looking a gift horse in the mouth, but in this case the 'horse' analogy

I've always thought that often the best way to give is anonymously and I understand I'm looking a gift horse in the mouth, but in this case the 'horse' analogy might be appropriate. This isn't a criticism of the FreeBSD Foundation; I'm just raising a question about this gift and similar gifts for other FOSS projects: FOSS projects thrive on transparency; are such large anonymous gifts good for them? Think of a similar anonymous gift to a politician - in that case, humble anonymity isn't a good thing (it's a very imperfect analogy; I'm just trying to relate the issue to something familiar). I assume, maybe incorrectly, that the FreeBSD foundation knows who the donor is; should the wider community know who wields such influence? Will the donor want something in return, now or later? Is it a corporation or corporate leader who may want FreeBSD's cooperation later, perhaps to stay out of or to support a certain market segment or technology? A U.S. government entity such as In-Q-Tel, or an entity controlled by a foreign government? FreeBSD and the donor may both say, and even mean, that there are no strings attached, but it's similar to a parent saying they won't favor their own children; when that donor calls with a request, it is very hard to say no. Likely the donor is being very generous and should be thanked, not questioned. And of course, if the FreeBSD Foundation said they were turning down the gift for the reasons above, many would question that decision too.

tachion 10y ago
There is one very important thing here: FreeBSD != FreeBSD Foundation. FreeBSD Foundation accepts donations and pledges to support FreeBSD Project, but FreeBSD Project is an open source technical initiative that gets support from many sources, one of which is FreeBSD Foundation. Giving money to the Foundation with 'bad intent' has no influence on the FreeBSD Project, so, yeah, no stings attached here.
- hackuser 10y ago
  > 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.)
koolba 10y ago
What favor could they ask for? On one extreme it's "add the secret backdoor" (haha. As if!). On the extreme, it's "add a device driver for foo". Are you worried about the former? Are you concerned about the latter?
- dbcurtis 10y ago
  I'll write that device driver and slap a BSD license on it for $250k. Problem solved. Kidding asside, I'm just pointing out that there are cheaper and easier ways to get device drivers into BSD.
- tedunangst 10y ago
  "Please support this esoteric networking protocol, and then when somebody asks for a different protocol, tell them sorry, the code is getting too complicated."
Tloewald 10y ago
The only thing that truly protects open source from corruption is the fact that it's open source. We can look at the code and we can fork it or choose not to use it or, as most of us do, rely on other people looking at it. Surely if a bad actor wants to do nefarious things to the code base there are cheaper and more reliable methods, such as simply becoming trusted contributors and sneaking in back doors.
- digler999 10y ago
  > such as simply becoming trusted contributors and sneaking in back doors. or just finding a critical developer on the team and paying him/her the same anonymous $500k "donation" to sneak the vulnerability into the code.

tachion 10y ago

There is one very important thing here: FreeBSD != FreeBSD Foundation. FreeBSD Foundation accepts donations and pledges to support FreeBSD Project, but FreeBSD Project is an open source technical initiative that gets support from many sources, one of which is FreeBSD Foundation. Giving money to the Foundation with 'bad intent' has no influence on the FreeBSD Project, so, yeah, no stings attached here.

hackuser 10y ago
> 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.)

koolba 10y ago

What favor could they ask for? On one extreme it's "add the secret backdoor" (haha. As if!). On the extreme, it's "add a device driver for foo". Are you worried about the former? Are you concerned about the latter?

dbcurtis 10y ago
I'll write that device driver and slap a BSD license on it for $250k. Problem solved. Kidding asside, I'm just pointing out that there are cheaper and easier ways to get device drivers into BSD.
tedunangst 10y ago
"Please support this esoteric networking protocol, and then when somebody asks for a different protocol, tell them sorry, the code is getting too complicated."

Tloewald 10y ago

The only thing that truly protects open source from corruption is the fact that it's open source. We can look at the code and we can fork it or choose not to use it or, as most of us do, rely on other people looking at it. Surely if a bad actor wants to do nefarious things to the code base there are cheaper and more reliable methods, such as simply becoming trusted contributors and sneaking in back doors.

digler999 10y ago
> such as simply becoming trusted contributors and sneaking in back doors. or just finding a critical developer on the team and paying him/her the same anonymous $500k "donation" to sneak the vulnerability into the code.