"There's no actual problem to be solved" -> Does a question have to be about a problem? I don't see it specified on superuser.com/help/on-topic. Many questions posted on this website aren't about problems, e.g. How does a computer restart itself?, which has received 483 upvotes and 3 downvotes so far.
Questions just seeking general knowledge are fine, because there are many different ways to approach answering them with valid and correct answers.
But very specific questions about the internals of proprietary software often won't ever be answerable by anyone except an employee of the company that wrote the software. A few proprietary software vendors do in fact participiate in Q&A on the network, but 99% of the time, asking questions like this is not really productive, because the "answers" you get will be someone's guess, supposition, or opinion (which is not terribly likely to be right) by making inferences based on the outward behavior of the software.
Or perhaps rather than offering a true answer, the answer might come in the form of "here's a series of possibilities, any of which might be the actual case, but we have no way of narrowing it down any further". And this sort of answer might be technically correct in that the assertions it makes are valid possibilities, but it isn't a true answer in the SE sense because it doesn't pin down a particular scenario as being factually correct.
In many cases we have to treat questions about proprietary software like questions about the natural world that are unanswerable, unless we expect the software vendor to pull back the curtains and give us an actual answer. While you might argue that leaving the question open for eternity might be the better option here, in case the vendor ever does search for questions about their software to try and answer on SU, these questions are sometimes closed instead.
In other words, I don't think we have a firm policy on whether or not to close these questions, but you are extremely unlikely to receive a known-correct answer anyway unless it comes from the source (an employee who worked on BlueJeans' code or design). Since we don't currently know of any BlueJeans employees contributing answers to the site, closing the question is one valid way of responding to it.
One good argument for why to not leave the question open, is that you are likely to solicit "bad" answers from non-BlueJeans-employees while waiting your eternity for the remote possibility of a real answer. Someone might have an opinion or make some assumptions (which they aren't entitled to make) about the behavior of the software and write an off-the-cuff answer that, while it might satisfy your curiosity, doesn't actually deliver any factually-based knowledge, and may in fact be incorrect. But since nobody other than BlueJeans employees has access to the truth, no one would know whether to upvote or downvote the answer provided, unless we knew it was coming from an authoritative source.
And even if it did come from an authoritative source, we still wouldn't be able to verify the answer, necessarily. If the answer provided some testable statements that we could observe about the behavior of the software from the outside (without seeing the code), that'd be one thing. But if the answer just explains the source code without providing any way for us to verify it, it'd still be a bad answer.
So, to boil this all down, questions seeking an explanation / seeking knowledge should either be about observable behaviors of running software, and/or about open source software. Let's take these apart case-by-case:
- Questions about observable behavior of running software: This is basically where you ask a question whose answer can be empirically verified by a user of the software, even without access to the source code. Many valid questions about, e.g., Windows (which is proprietary) get asked in this format, where we're able to know the correctness or incorrectness of answers provided by testing it out ourselves. Your question here, on the other hand, does not ask something that we can go test. You're asking about an algorithm which can be literally anything. We can all see the participant numbers on our BlueJeans software, but we don't know how that number is being derived, and anyone can only guess.
- Questions about open source software: Because open source software provides access to the code, it doesn't matter if the question is about the innards of the software, because someone can always go download the code, read it, and give you a factual answer based on their understanding of the code (the behavior of code is objective, meaning there's only one correct way to interpret any sequence of code). So in this case, knowledge-seeking questions are not limited to ones about the outward observable behavior of the software, because anyone can go grab the code.
It's this third case where the software is closed-source/proprietary and asking about the internals, where we're inclined to close it, especially when we have no prior knowledge of anyone from that company participating on SU, and where we expect that answers from non-employees are likely to be incorrect (and furthermore, even an answer from an employee would just be "taking their word for it", because we couldn't independently verify the answer, more likely than not).
I suppose, with great, great difficulty, one could eventually derive some sort of empirical formula for participant count by all manner of environmental data until they pinned down several independent variables that, combined together, produce some sort of equation for deriving the number of participants. But to come up with this sort of answer would basically be akin to Isaac Newton deriving the formula for the acceleration due to gravity. You would have to test probably hundreds of different scenarios, plot them on a graph, and eventually try to work out some apparent formula for the algorithm.
I guess, if you really want someone to try and do that, that would be the only answer I'd accept, outside a direct answer from an employee of BlueJeans that includes a code snippet of the algorithm. And in that case I suppose we could justify reopening the question. But a correct empirical answer would basically have to read something like this:
I ran a series of 100 meetings over two months using BlueJeans and actual known participant numbers ranging from 2 to 30. I captured environmental data such as the actual video contents, number of people on the teleconference line, and whether they're muted or unmuted. Based on my observation, BlueJeans seems to know when people connect to the teleconference by phone because it detects their connection to the meeting that way. So the participant count is derived from those joining the room using the software, plus those who've dialed into the audio teleconference number. I didn't find any difference in the participant count estimate based on whether folks were muted, unmuted, or talking.
It's kind of funny, because the real world outside of software (e.g., in the physical sciences) doesn't have "source code" we can just go read. So when someone wants to determine truths about the real world, we have to do actual research like this, by conducting experiments, making observations, and then making inferences from those observations about what equations seem to fit the data. That's sort of what you'd be asking of an answerer here, unless, again, they were the software equivalent of "God" (or the creator, however you wish to refer to them/it/him/her) and could provide an authority on the matter based on the objective truth revealed by the source code.
And normally I would laud any attempts to perform original research, either in the physical sciences or in software. But I don't think that serious experimental research like this really belongs on SU, especially when the topic of the research is just observations about the behavior of proprietary software, which, in the end, is just a human-crafted contraption that has an objective truth about its behavior -- we just don't have access to it because it's proprietary.
Sorry for the long and winding answer; it's an interesting question and I don't think there's any hard and fast rule that I'm happy with here.
