meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
ancient_history [2020/10/30 01:08] – [JavaCC Project History] revuskyancient_history [2020/10/30 15:55] – [Another name change. JavaCC (21)] revusky
Line 113: Line 113:
 A couple of people have expressed misgivings about my taking the JavaCC name. One person said that this would "create confusion". I agree that there is potentially an issue there. However, my position is that the people creating confusion are the people running the legacy JavaCC project. In general, the people running a [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] project are the ones "creating confusion" because, like it or not, a cold-blooded analysis of the situation is that they are basically perpetrating a fraud, trying to portray an inactive project as something active. A couple of people have expressed misgivings about my taking the JavaCC name. One person said that this would "create confusion". I agree that there is potentially an issue there. However, my position is that the people creating confusion are the people running the legacy JavaCC project. In general, the people running a [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] project are the ones "creating confusion" because, like it or not, a cold-blooded analysis of the situation is that they are basically perpetrating a fraud, trying to portray an inactive project as something active.
  
-A [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] is essentially a fraud, because it amounts to artfully arranging your bun and your condiments and creating a //trompe l'oeil// so that people get tricked into thinking there is actually some beef in there.+A [[nothingburger]] is essentially a fraud, because it amounts to artfully arranging your bun and your condiments and creating a //trompe l'oeil// so that people get tricked into thinking there is actually some beef in there.
  
 Meanwhile, //JavaCC 21// is what it is being presented as, the active continuation of work on the codebase that Sun open sourced back in 2003. Meanwhile, //JavaCC 21// is what it is being presented as, the active continuation of work on the codebase that Sun open sourced back in 2003.
Line 121: Line 121:
 //Nobody has ever filed a trademark in any jurisdiction on the name JavaCC.// //Nobody has ever filed a trademark in any jurisdiction on the name JavaCC.//
  
-In any case, the problem here is that this is the only feasible course of action. In the open source world, it frequently happens that people show up in a community, one of these [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] projects and propose some ideas and they are arrogantly dismissed and the people are told that they are free to go "fork" the project.+In any case, the problem here is that this is the only feasible course of action. In the open source world, it frequently happens that people show up in a community, one of these [[nothingburger]] projects and propose some ideas and they are arrogantly dismissed and the people are told that they are free to go "fork" the project.
  
 Well, this is technically true. You can create your own "fork" of an open source project, but the problem is that a project of the vintage of JavaCC has such an immense visibility advantage that it is not really feasible to fork off one's one version and "compete" with that. Now, your version is bound to be technically superior. But that does not really matter. Your version will receive almost zero attention and usage. It's fairly easy to see why this would be the case. You just have to visualize some person sitting in a cubicle in the corporate world out there, who is tasked with figuring out the tool stack to use for whatever project. That person will almost never download something like JavaCC and then download FreeCC and make a technical comparison between the two. For starters, in most cases, he never will have heard of FreeCC in the first places. But, more importantly, once something is well established as a standard thing in its space, rightly or wrongly, it will be perceived in the corporate world as the "safe" option. Our imaginary cubicle occupier is taking no risk by advocating the use of JavaCC, but if he did advocate something called "FreeCC" instead, he would be sticking his neck out and people would ask him: "Why not just use the standard thing?" (Which would be JavaCC in this case.) Well, this is technically true. You can create your own "fork" of an open source project, but the problem is that a project of the vintage of JavaCC has such an immense visibility advantage that it is not really feasible to fork off one's one version and "compete" with that. Now, your version is bound to be technically superior. But that does not really matter. Your version will receive almost zero attention and usage. It's fairly easy to see why this would be the case. You just have to visualize some person sitting in a cubicle in the corporate world out there, who is tasked with figuring out the tool stack to use for whatever project. That person will almost never download something like JavaCC and then download FreeCC and make a technical comparison between the two. For starters, in most cases, he never will have heard of FreeCC in the first places. But, more importantly, once something is well established as a standard thing in its space, rightly or wrongly, it will be perceived in the corporate world as the "safe" option. Our imaginary cubicle occupier is taking no risk by advocating the use of JavaCC, but if he did advocate something called "FreeCC" instead, he would be sticking his neck out and people would ask him: "Why not just use the standard thing?" (Which would be JavaCC in this case.)