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 revision		Previous revision
ancient_history [2020/10/30 01:08] – [JavaCC Project History] revuskyancient_history [2020/10/30 15:57] (current) – [Another name change. JavaCC (21)] revusky
Line 105: Line 105:
 Now, first of all, to be clear about one aspect of all of this, FreeCC (now //JavaCC 21//) was never a "fork" in any real sense. A fork, i.e. a //bifurcation//, contains the implict idea that there are two (or possibly more) lines of //active development//. That is simply not the case here. As far as I know (and I would surely know it by now if this were not the case) the body of work that I did from Spring of 2008 to very early 2009, and am now resuming, is the //only// work of //any significance// that has been done on the JavaCC codebase that Sun open sourced back in 2003. Soon, that will have been 17 years ago and I do not believe that the amount of work done by the ostensible project maintainers amounts to what a single motivated person could do in a single month. There are some other people who got frustrated with the obstructionism of the canonical project maintainers and created their own "forks" of the codebase. However, I do not believe that any of them constitute a body of work remotely comparable to what was done on FreeCC. Now, first of all, to be clear about one aspect of all of this, FreeCC (now //JavaCC 21//) was never a "fork" in any real sense. A fork, i.e. a //bifurcation//, contains the implict idea that there are two (or possibly more) lines of //active development//. That is simply not the case here. As far as I know (and I would surely know it by now if this were not the case) the body of work that I did from Spring of 2008 to very early 2009, and am now resuming, is the //only// work of //any significance// that has been done on the JavaCC codebase that Sun open sourced back in 2003. Soon, that will have been 17 years ago and I do not believe that the amount of work done by the ostensible project maintainers amounts to what a single motivated person could do in a single month. There are some other people who got frustrated with the obstructionism of the canonical project maintainers and created their own "forks" of the codebase. However, I do not believe that any of them constitute a body of work remotely comparable to what was done on FreeCC.
  
-As I have stated quite bluntly above, the legacy JavaCC project is just one of these [[https://doku.javacc.com/doku.php?id=nothingburger|Nothingburger]] projects. (It is not the only one out there!) Properly understood, it is not even about the people involved in the project currently. I do not recognize the names of most of the people involved in that currently. However, it doesn't matter. There is no remotely realistic prospect of them ever doing anything for a very simple reason:+As I have stated quite bluntly above, the legacy JavaCC project is just one of these [[nothingburger]] projects. (It is not the only one out there!) Properly understood, it is not even about the people involved in the project currently. I do not recognize the names of most of the people involved in that currently. However, it doesn't matter. There is no remotely realistic prospect of them ever doing anything for a very simple reason:
  
 //Nothing significant can be done with the legacy JavaCC codebase without a massive cleanup and refactoring.// //Nothing significant can be done with the legacy JavaCC codebase without a massive cleanup and refactoring.//
Line 111: Line 111:
 I undertook that cleanup and refactoring back in 2008 and it is largely done. The only basis for moving forward on the project is [[https://github.com/javacc21/javacc21|my version of the codebase]], the one that has been cleaned up. I undertook that cleanup and refactoring back in 2008 and it is largely done. The only basis for moving forward on the project is [[https://github.com/javacc21/javacc21|my version of the codebase]], the one that has been cleaned up.
  
-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 [[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.)