While broadly right this has some inaccurate parts, in particular:
> If we were talking about OpenGL, there would be absolutely nothing you can do. In OpenGL or other older APIs, it’s only possible to do API calls from one thread.
Isn't really true. You can load textures off thread[1] and other things which come in handy. Vulkan expands that but I've done multithreaded texture loading for instance almost a decade ago.
This is particular important if your not loading compressed textures as there's usually a tiling/swizzle pass and the texture copy can be significant on large textures(unless you're using something like eglCreateImageKHR).
The fact that this "mistake" occurs so frequently and is so trivial to make just tells me that the meaning you want it to have will not survive in the long run.
You are correct that it isn't Open Source as defined by the Open Source Initiative, nor does it use an Open Source Initiative Approved License.
None of that information, however, is helpful to the author or really changes anything about the article.
It's an extremely important distinction. There's a term for software like Unreal Engine, which is "source available", and the difference between this and "open source" has massive categorical differences in terms of what you can legally do with this source code.
If an important distinction like this is fading from our language, it's probably evidence that newer members of the community haven't been fully educated on the implications of software licensing terms, and if that's the case we should focus on improving that education, not resign ourselves to important knowledge being lost by the community.
For instance, if you learned that young people were not aware of the dangers of exposure to lead, you would not throw up your hands and say: "I guess we'll just start using lead pipes again". You would make an effort to pass on that knowledge.
I agree with your position. Open Source is not a meaninglessly unclear term, it is a precise term of art. It makes good sense to resist efforts to turn it into a meaningless marketing term like premium.
Some people point out that the term isn't trademarked. That doesn't matter. That isn't how terms of art work.
It's confusing to me too when it's phrased that way. Stallman's original quote makes much more sense, "Think free as in free speech, not free beer." In other words, contrasting free as in "no restrictions", versus free as in "no cost".
If you see a sign advertising “Free Beer” you understand that the meaning of “free” in this context means “goods and/or services available at no cost”. The English word “free” means a lot of things and the meaning of “free” in the expression “Free Beer” is very different from the meaning in the expression “Free Speech”, where it is used to mean “not legally restricted”.
I always thought “free as in beer” meant that you could make your own beer if you were willing to put the discovery, learning, and work in to make it happen. And you were responsible for the output.
Language develops according to how people actually use it. There are two competing camps on the meaning of "open source"; I understand why there is a battle over it on ideological grounds, but I don't think it is necessarily a mistake, more of a different side of the debate. Much like how some people are pedantic about calling them "tissues", while a large body of people know the difference but just go on calling it kleenex. Not wrong, just a different culture of usage.
One of the camps are members of the open source movement (developers, promoters and satisfied users) and the other comes from corporations trying to co-opt the term and its good reputation.
It's not really a "everyone has a right to an opinion" type of situation.
You can go on and support the dilution of the term, just remember when the software development culture has another turn to the worst, you had been a part of the problem.
The official definition of “open source software” [..] agrees with our definition in most cases.
However, the obvious meaning for the expression “open source software”—and the one most people seem to think it means—is “You can look at the source code.” That criterion is much weaker than the free software definition, much weaker also than the official definition of open source.
[..]
Since the obvious meaning for “open source” is not the meaning that its advocates intend, the result is that most people misunderstand the term.
"Free" is also ambiguous in English, even more than "open". I suppose "libre" is explicit but also not an actual common word.
"Open" is clear, widely accepted by the community including businesses, and is defended by the Open Source Initiative (think of them what you will, they do a good job of keeping that definition true, by doing things such as approving licenses).
"Open" has also been extended to other areas, such as "open science" (which does not refer to science for which a paper is available, but to actual reusable science).
I don't see any problem with "open", other than the fact RMS doesn't like it.
> "Open" has also been extended to other areas, such as "open science" (which does not refer to science for which a paper is available, but to actual reusable science).
That meaning predates the use of "open" to describe software, hence why "open source" isn't that great of a term for something truly new. It co-opts the much older term "open source" which means freely available through non-protected sources. Like, in the intelligence services "open sources" has meant non-classified, non-restricted sources. There's a similar meaning in journalism.
'open' and 'source' are also just two words of the English language which have an implied meaning when put together. I do not think any initiative can ban the normal meaning of language. It is like saying the 'real beef initiative' declares the meaning of the word 'real beef' to only apply to kobe beef.
Also how would you actually call software where the source is open but does not fulfill the osi criteria?
> 'open' and 'source' are also just two words of the English language which have an implied meaning when put together.
Right, which is further evidence against the assertion that '"open source" means absolutely nothing'.
> Also how would you actually call software where the source is open but does not fulfill the osi criteria?
I tend to use the term "transparent software". Goes hand-in-hand with my catchphrase[0] 'round these parts. Basically: if I can see the source code (and therefore can independently audit it, or hire someone to do so), then it's transparent and can (potentially) be trusted, even if the license infringes on my freedoms around that source code (modification, redistribution, etc.).
Threaded OpenGL is something you only do if you either have a death wish or a phone number you can dial to speak to a VP at NVIDIA. Everyone I know who's shipped it in games regretted it, and I've had driver developers explicitly tell me I shouldn't bother.
Yeah, it’s technically supported, and I have seen the patient ship it in limited use. But it’s certinally not a well tested path and the stability leaves a lot to be desired.
Loading buffers and textures are about the only things that are kind of stable in multithreaded OpenGL. This is the probably the only use case anybody cares about. Go beyond that and you'll have a high chance to hit strange driver bugs.
Good catch, i was unaware that loading textures off threads in opengl was possible, given that ive never seen it used even on commercial engines. Ill update the article to reflect that.
In my experience, even the best Android drivers just took locks when using OpenGL from multiple threads, even for resource creation, so it's sort of moot.
That depends largely on the driver. It's not a guarantee but I've seen pretty solid perf wins on the drivers that support it.
From a hardware perspective just about every Android SoC minus a few odd ones have unified memory so there's really no reason for them to take a lock, at least for the heavy part of the operations that copy the texture and tile/swizzle.
sometimes I cry a little over the fact that people who only have access to under powered phones are the most incentivised to criticise apps despite being consigned to ultimate futility regardless of their actions, whilst it's a rare occasion when the owner of a flagship phone is going to give feedback of any kind about performance to the developers of a poorly performing app that may be software atrocities but given more hardware than the average high end laptop to consume...
> If we were talking about OpenGL, there would be absolutely nothing you can do. In OpenGL or other older APIs, it’s only possible to do API calls from one thread.
Isn't really true. You can load textures off thread[1] and other things which come in handy. Vulkan expands that but I've done multithreaded texture loading for instance almost a decade ago.
This is particular important if your not loading compressed textures as there's usually a tiling/swizzle pass and the texture copy can be significant on large textures(unless you're using something like eglCreateImageKHR).
[1] https://www.khronos.org/opengl/wiki/OpenGL_and_multithreadin...