|
Thanks very much for replying, and for the link! One of the biggest differences I've noticed between open source and "the cathedral" is that commercial endeavors that revolve around productization tend (as a rule) to manifest sufficient runway to fully round out the implementation of an idea to the point the implementation can participate in the market cohesively by representing itself attractively/competitively. This is often a broad-spectrum effort that requires domain specialization across a huge number of skills, and the burden of sustaining cohesive focus is typically only viable in a commercial context; I think similar levels of adequate collective focus (many individuals, one goal) are only typically raised in cult-type contexts. Besides the passion-project foundation you mentioned, a lot of open source seems to come into existence because an $employer needed a really specific thing one time and they let the developer license the code under GPL and here it is and there's the 2.8 pages of documentation and it's got some speling misteaks in it and hopefully it works. (...Woops, I just described NPM, and some percentage of PyPI.) Very very problematically, there's no collective language in the FOSS scene to distinguish between passion projects and commercially-driven JIT-developed code-dumps. After all, the code probably has just as many bugs per 1,000 lines, and the different contexts produce results that work the same, so...? IMO, being able to encode that attribution to our communication would make SO MUCH difference in terms of user support, project coordination, etc! Coming from a perspective that's still optimistic :), arguing that "this is great, but it doesn't fit our business use case" translates for me to "my contract doesn't extend to me implementing/grokking/mentally integrating/testing/maintaining this new code, and it's not interesting enough for me to figure it out out of hours either" - so the invitation really is there, "send patches in if they're important enough to you", but it requires working cue perception (and possibly lack of cynicism) in all readers in order to be interpreted correctly. IF this is in fact the message that was being sent (!). That the followup work was not done does indeed waste the effort made by the patch author, and is generally arguably stupid. But this to me brings up questions about the patch author's motivations, and why they didn't have a go at hammering everything into place - because, assuming fully adequate motivation/stamina and sufficient free time to iterate on the patch until the mailinglist likes it, eventually you'll reach a point where either the patch is in a staging tree somewhere, or the list has exploded into a flamewar about why the patch hasn't been accepted already, at which point (continuing to assume ideal circumstances) the patch author could go follow up on all the raised points. I guess the outcome depends on whether the patch author considers the above AbSoLuTeLy ToO MuCh WoRk SeRiOuSlY ArE YoU KiDdInG Me, or welcomes the community involvement/participation/feedback and does their best to negotiate it to the point of getting the code merged. That the patch author didn't do this is something only they can provide extra context and judgement about; as you noted about speculation, I could only come up with uncited hypotheses here. Looping back to the first paragraph, there are indeed many instances, for example in the audio/image/video editing scene, where software availability for Linux is incredibly restricted compared to Windows. The options are there, except they don't really work, or they fall over really quickly, or they feel really clunky. I think this sadly comes down to market demand. For example I've tried poking around with simple audio editing tasks - literally just loading a couple of tracks and crossfading them together - on Linux, and come up blank. Pop culture saturation might also be a factor, for example Renderman and Maya have been around for Linux for ages, but it's sliiightly (I suspect) easier to find "how to <jmp> over the license check" thingys for After Effects or Photoshop, for example. However, with all of this being said, I have noticed a few industries where the comparison of feature parity in what's available in open source vs what's available commercially is sufficiently vast it directly leads to actual mental disorientation ("wait, this is where things are really at??"). It's incredibly difficult in this situation to stay non-cynical and not draw the types of conclusions you allude to in these settings (that perhaps there are agreements in place to not implement certain features, for example). And it's kind of interesting how "get Photoshop" is kind of a thing - an obscure thing, but still a thing that happens, while this seems (generally speaking) to happen less to Eyewateringly-Expensive Software™ targeted at Linux (?). I guess this reply was me doing the (googles) denial-anger-bargaining-depression-acceptance thing while reasoning through your comment and trying to not be cynical :D, haha. It certainly is one of those worldview classification grey areas, where it's almost like it can be both things at once (except it can't, because that wouldn't make sense)... I do also definitely agree that a lot of open-source development work is unfairly leveraged, and additionally that the "learning to code" movement (yay, more labor externalization!) is overhyped, almost to the point of the cult thing I noted above. |