3 ms·

I admit to a certain level of exaggeration but, at the same time, we are talking literal peanuts to a large company. They could spend a million dollars and it'

by bshipp 5y ago

I admit to a certain level of exaggeration but, at the same time, we are talking literal peanuts to a large company. They could spend a million dollars and it'd be a rounding error on their balance sheet. In all seriousness, taking actions like I identified above would cost the companies virtually nothing but result in huge long-term benefits by signaling to the rest of the open source world that "we love your work and will be right beside you helping if the chips are down." This is, of course, not a suitable compensation model for popular open source projects. Thats a separate conversation. But it would at least be something.

dylan604 5y ago
if this was a difficult task to fix, maybe support to ensure the devs can properly focus on the task would be a valid thing. however, this sounded like something not very difficult to fix. it will take longer for all of the end users to deploy fixes in their envs that it took for the patch to become available. molehill meet mountain.
antonvs 5y ago
The compensation model is the problem. It doesn't mesh well with the way corporations function. If you don't charge for your product or services, corporations have no standard mechanism for addressing that some other way. Open source contracts essentially state that companies can use the product with no relevant obligations, so they do. The "huge long term benefit" you claim can't be reliably translated onto a balance sheet, so it isn't. And when companies do get involved, it's often explicitly for their direct commercial benefit, like Amazon's ElasticSearch distribution. There's also a race to the bottom aspect to it. If an open source package e.g. charges for commercial use, something more free is likely to replace it.
- jancsika 5y ago
  > The compensation model is the problem. It doesn't mesh well with the way corporations function. If you don't charge for your product or services, corporations have no standard mechanism for addressing that some other way. FSF: Pardon me, here's a little process that encourages sharing so that everyone can... Corporations: gnawing on a giant proprietary turkey leg Doesn't Mesh Well nom nom nom No Standard Mechanism nom nom nom ** Corporations: yelling through a mouthful of turkey What in sam hell is Linux why does IBM have a billboard about Linux why don't we have Linux? Underling: Sir that's open source, our standard licensing mechanism wouldn't... Corporations: belching through a mouthful of turkey change the goddamned mechanism I want linux and pass me that mayo
  - antonvs 5y ago
    > Pardon me, here's a little process that encourages sharing But they're following the process. What the comment I replied to was saying was that they should go beyond it. I'm pointing out that the lack of standard processes for doing that is what prevents it from happening. That's just the reality of the situation. Yelling at clouds isn't going to change that.
throw_log4jfang 5y ago
> I admit to a certain level of exaggeration but, at the same time, we are talking literal peanuts to a large company. I'm not sure you understand what you are asking, and I'm kind of dumbfounded by the sense of entitlement of your request. You are expecting others like me to be forced to work weekends on a problem that doesn't concern me (because my service is already patched) for absolutely nothing in return, and instead risking owning a problem and the blame of not coming up with a one-size-fits-all magic bullet. All downsides and absolutely no upside at all, for my employer and let alone for myself. Let me ask you this: how much of your personal time did you invested in coming up with a fix for this vulnerability? And yet you feel entitled to demanding this from others?
- detaro 5y ago
  You do realize that this issue wasn't discovered this morning, and indeed part of the point is that if it wasn't people in their spare time it could've been patched days ago, and you could've fixed all your services during the week? So you prefer working weekends to fix a delayed bug instead of devs being paid to help fix it for everybody during the working week?
  - raggi 5y ago
    > Usually (as per ASF rules) the team should wait 72 hours after creating a release candidate before publishing the release to give the community enough time to review and cast their votes. We are building consensus to shorten that window for this particular release, given its urgency. from: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990264908 https://github.com/apache/logging-log4j2/pull/608#issuecomme... If you read more of the history of the release you'll find that additional vectors were found in the RC process that were also fixed.
- deleted 5y ago
  [deleted]
raggi 5y ago
This commentary is exactly the problematic commentary the authors were referring to in the quote that David included near the top of his article. You may not be being so directly brash about their state, but you still imply with added dramatic extension that the project is in some dire state. That's likely a significant overreaction. There's a feature in the project that leads to a security concern, making it fixable likely took a small number of hours, communicating and dealing with the drama is what has and would continue to take the time, as well as pushing back on a plethora of demands for "full review" or "you must travel outside of your home country so I feel comfortable again". I poked some fun at the issue, because this is in many ways an amusing issue - a feature that would rarely be added in more recent times, but at the time it was introduced we as an industry considered the whole space differently. I'm sure the maintainers are having a tough time, and theres no need to point fingers at them, hell there's no need to point fingers at the implementor of the feature. It's a mistake in retrospect but that doesn't make anyone unworthy of respect. The actions you identified make a lot of assumptions, some are exclusionary, some are potentially offensive: - not everyone lives in the same country - not everyone can travel on a whim - the developers don't need to be close to you or their customers unless they want to be. - the project is not in some dire state in need of "saving" As an Apache project there is a foundation that can help organize funding, and so if there's a funding problem with the project the discussion should start there. Yes, open source at large is underfunded, but this isn't a standalone project on a personal git host. Apache has some (probably not enough) funding, but most importantly it has the industry contacts and relationships to do better here. There's a problem with "doing better" though, which I rarely see come up in these conversations. There are lots of libraries, such as log4j, that don't necessarily need full time staff or full time funding. They need spurts of funding at key times, to handle the trickle of regular but infrequent patches, to roll releases periodically, and occasionally such as this to dedicate some significant time to handling an exceptionally rare event. What this requires, in my opinion, more than arbitrary dollars, is a slush fund of professional time sponsorship, for employers of key contributors to be ready to make space available during work hours for this work, without adding any more pressure to the situation. Depending on the situation this may or may not require additional funding, but for a healthy ecosystem finding ways to arrange for this, and helping employers be comfortable with it is the step necessary to address the wide scale problem of small to mid size projects burning people's personal time in unplanned ways.

by bshipp 5y ago

dylan604 5y ago

if this was a difficult task to fix, maybe support to ensure the devs can properly focus on the task would be a valid thing. however, this sounded like something not very difficult to fix. it will take longer for all of the end users to deploy fixes in their envs that it took for the patch to become available. molehill meet mountain.

antonvs 5y ago

The compensation model is the problem. It doesn't mesh well with the way corporations function. If you don't charge for your product or services, corporations have no standard mechanism for addressing that some other way. Open source contracts essentially state that companies can use the product with no relevant obligations, so they do. The "huge long term benefit" you claim can't be reliably translated onto a balance sheet, so it isn't. And when companies do get involved, it's often explicitly for their direct commercial benefit, like Amazon's ElasticSearch distribution. There's also a race to the bottom aspect to it. If an open source package e.g. charges for commercial use, something more free is likely to replace it.

jancsika 5y ago
> The compensation model is the problem. It doesn't mesh well with the way corporations function. If you don't charge for your product or services, corporations have no standard mechanism for addressing that some other way. FSF: Pardon me, here's a little process that encourages sharing so that everyone can... Corporations: gnawing on a giant proprietary turkey leg Doesn't Mesh Well nom nom nom No Standard Mechanism nom nom nom ** Corporations: yelling through a mouthful of turkey What in sam hell is Linux why does IBM have a billboard about Linux why don't we have Linux? Underling: Sir that's open source, our standard licensing mechanism wouldn't... Corporations: belching through a mouthful of turkey change the goddamned mechanism I want linux and pass me that mayo
- antonvs 5y ago
  > Pardon me, here's a little process that encourages sharing But they're following the process. What the comment I replied to was saying was that they should go beyond it. I'm pointing out that the lack of standard processes for doing that is what prevents it from happening. That's just the reality of the situation. Yelling at clouds isn't going to change that.

throw_log4jfang 5y ago

> I admit to a certain level of exaggeration but, at the same time, we are talking literal peanuts to a large company. I'm not sure you understand what you are asking, and I'm kind of dumbfounded by the sense of entitlement of your request. You are expecting others like me to be forced to work weekends on a problem that doesn't concern me (because my service is already patched) for absolutely nothing in return, and instead risking owning a problem and the blame of not coming up with a one-size-fits-all magic bullet. All downsides and absolutely no upside at all, for my employer and let alone for myself. Let me ask you this: how much of your personal time did you invested in coming up with a fix for this vulnerability? And yet you feel entitled to demanding this from others?

detaro 5y ago
You do realize that this issue wasn't discovered this morning, and indeed part of the point is that if it wasn't people in their spare time it could've been patched days ago, and you could've fixed all your services during the week? So you prefer working weekends to fix a delayed bug instead of devs being paid to help fix it for everybody during the working week?
- raggi 5y ago
  > Usually (as per ASF rules) the team should wait 72 hours after creating a release candidate before publishing the release to give the community enough time to review and cast their votes. We are building consensus to shorten that window for this particular release, given its urgency. from: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990264908 https://github.com/apache/logging-log4j2/pull/608#issuecomme... If you read more of the history of the release you'll find that additional vectors were found in the RC process that were also fixed.
deleted 5y ago
[deleted]

raggi 5y ago

This commentary is exactly the problematic commentary the authors were referring to in the quote that David included near the top of his article. You may not be being so directly brash about their state, but you still imply with added dramatic extension that the project is in some dire state. That's likely a significant overreaction. There's a feature in the project that leads to a security concern, making it fixable likely took a small number of hours, communicating and dealing with the drama is what has and would continue to take the time, as well as pushing back on a plethora of demands for "full review" or "you must travel outside of your home country so I feel comfortable again". I poked some fun at the issue, because this is in many ways an amusing issue - a feature that would rarely be added in more recent times, but at the time it was introduced we as an industry considered the whole space differently. I'm sure the maintainers are having a tough time, and theres no need to point fingers at them, hell there's no need to point fingers at the implementor of the feature. It's a mistake in retrospect but that doesn't make anyone unworthy of respect. The actions you identified make a lot of assumptions, some are exclusionary, some are potentially offensive: - not everyone lives in the same country - not everyone can travel on a whim - the developers don't need to be close to you or their customers unless they want to be. - the project is not in some dire state in need of "saving" As an Apache project there is a foundation that can help organize funding, and so if there's a funding problem with the project the discussion should start there. Yes, open source at large is underfunded, but this isn't a standalone project on a personal git host. Apache has some (probably not enough) funding, but most importantly it has the industry contacts and relationships to do better here. There's a problem with "doing better" though, which I rarely see come up in these conversations. There are lots of libraries, such as log4j, that don't necessarily need full time staff or full time funding. They need spurts of funding at key times, to handle the trickle of regular but infrequent patches, to roll releases periodically, and occasionally such as this to dedicate some significant time to handling an exceptionally rare event. What this requires, in my opinion, more than arbitrary dollars, is a slush fund of professional time sponsorship, for employers of key contributors to be ready to make space available during work hours for this work, without adding any more pressure to the situation. Depending on the situation this may or may not require additional funding, but for a healthy ecosystem finding ways to arrange for this, and helping employers be comfortable with it is the step necessary to address the wide scale problem of small to mid size projects burning people's personal time in unplanned ways.