A similar situation happened to me, but obviously on a smaller scale. I added support for using pixel shaders on emulated video game output, but rather than ha

A similar situation happened to me, but obviously on a smaller scale. I added support for using pixel shaders on emulated video game output, but rather than have separate files for the vertex and fragment shaders, I put the pair into an XML file, and also included settings for min/mag filter, texture format, etc there as well; so that it was all self-contained as a single file that you could paste on a forum. I released this, and some other people liked the idea, but wanted it to support multiple shader passes. Which was great! I wanted to add this, but had a lot of much higher priority items on my plate and couldn't get to it quickly enough. So they went ahead and added multi-pass, texture lookup, reflection, and a whole bunch of other neat features without consulting me, released their own software and then called it "version 1.1", while continuing to support my spec as "version 1.0" The results were obvious: lots of users coming to me to ask why their XML shaders weren't working, which turned out to be because they were using a different standard. Shader writers began targeting 1.1 syntax even without using any additional features, which needlessly took away compatibility with my own program. This wouldn't have been so bad, I could have just supported their new spec once I had time, except that they took the spec in a direction I felt was flawed and against the spirit of it. Referencing external texture files which created file naming conflicts (shader A and shader B both loading their own separate versions of texture.png), losing the ability to post them as inline text on forums, having very inconsistent syntax to what I had been doing, features that were vague in their combinatorial effects, etc. I ultimately had to abandon my own (retroactively named for me) "version 1.0" specification and start on an entirely new format to resolve that ambiguity. They were certainly in the right and clear to do the work that I wouldn't, but I do regret that they took my name, and ended up causing a lot of confusion for end users. And now I worry about this happening to all of my formats (I have a markup format, a delta-based binary diff tool, the new multi-pass shader format, and a few others.) I could try and come up with some licensing term that would most certainly get all of my software kicked out of Debian's main repositories; but there's really no way for me to stop anyone from fragmenting my specifications again, as I simply don't have the money nor desire to trademark things and attempt to sue people for enforcement. So, with that said ... I'm with John Gruber on this. If he is asking them to change the name, they should change the name. It's just the polite thing to do. Even if Gruber is a terrible steward, he created it. Keeping Markdown in the name is clearly just intended to capitalize on the success of the format, which they themselves did not earn.