This thread made me look at Clojure again (it has been a few years since the last time). Searching for Bayesian inference libraries I came across this: https://github.com/cemerick/raposo
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)
The author is saying those things about his own talks, not generally of everyone. Unless you're trying to claim they are never true in any case, I don't think there's anything to disagree about here.
I understood that the attendance’s irritarion and the “acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question" would also apply to someone else’s talks. But I see how the availability aspect could be part of his talk, or is expected because of who he is. If it’s about himself/his talks in particular another option would be to change the expectations.
I think you're over-parsing this. The document you linked is basically an apology - the guy's saying "if you came to this repo looking for the code for that talk I gave, it's not here, and sorry about that, and here's why I regret that and how I'll avoid repeating my mistake". Considered in context, it's clearly not a "here's what I think other people ought to do" kind of document.
> the “people find presentations about code or libaries for which the source is not available irritating” seems to be a general statement.
Read the whole thing in context. He's apologizing for jumping the gun - for giving a talk about a library he intended to release, before it was ready. The implication is that it was probably a "hey try this library!" kind of talk, that has little value to the audience without the code, so he's saying he should have waited.
Giving talks about closed code that will never be released is separate from all that, and clearly not what he's talking about. Hence the exception, "case studies and such".
Fine, I see how it can mean that. But even reading it in context I don’t think that “the implication” was obvious. Of course, a talk based of unfulfilled promises can be irritating. It’s a good thing to avoid. No disagreement on that.
Sometimes I hear presentations just to learn how they approached a problem remotely similar to mine or used tools I am interested in using myself. The library and its exact implementation are mostly irrelevant in that case.
One thing that I've found increasingly distasteful (I've noticed it in the React community, but it may be a wider trend), is the use of conference talks to announce/launch projects.
Thankfully it's still usually the case that the content of the talk is generally valuable. But ultimately, if I'm paying to fly somewhere and see your talk, I'm there to learn, not to witness your own self-promotion.
I guess it's no worse than the other main use of conference talks I've seen, which is to hawk the speaker's latest book. Maybe that's diminished somewhat, I have not been to many conferences lately but 10-15 years ago it seemed like most talks were peppered with phrases like "I talk more about this in my book..."
It's possible I was lucky with some of the conferences I went to, which had talks very much in the vein of "here's a new/different way to think about things". And I don't mind people using their own projects/products as a demonstration of what they're trying to communicate. But when they start to feel like Apple's product announcement keynotes, it feels something has gone wrong.
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)