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
Next revisionBoth sides next revision
nothingburger [2020/05/23 14:27] – [What is to be done?] revuskynothingburger [2020/05/25 17:07] revusky
Line 7: Line 7:
 Practically everybody uses Git nowadays but back then the standard thing was CVS, which was what Java.net used. CVS may be more crufty and capricious than Git, but if it is a question of just getting an overview of the history of a codebase, CVS serves perfectly well for that purpose. Practically everybody uses Git nowadays but back then the standard thing was CVS, which was what Java.net used. CVS may be more crufty and capricious than Git, but if it is a question of just getting an overview of the history of a codebase, CVS serves perfectly well for that purpose.
  
-Now, if I were a more masterful storyteller, I would find some way of building the suspense, to keep you waiting with bated breath. But I guess I'll just get straight to the point. Here is the summary conclusion of my code review of the time:+If I were a more masterful storyteller, I would find some way of building the suspense, to keep you waiting with bated breath. But I guess I'll just get straight to the point. Here is the summary conclusion of my code review of the time:
  
 //To all intents and purposes, **no** work had been done in those five years. **Nothing.**// //To all intents and purposes, **no** work had been done in those five years. **Nothing.**//
Line 13: Line 13:
 Now, to be clear, that is not to say that there was no commit record. However, none of it related to the real core, the guts of the codebase. Now, to be clear, that is not to say that there was no commit record. However, none of it related to the real core, the guts of the codebase.
  
-Well, what I am describing is actually a general phenomenon, and I had encountered it before. Still, at the time, I did not have any terminology to describe it, and if there is a generally accepted term out there, I am not aware of it. Here is what I propose:+What I am describing here is actually a general phenomenon, and I had encountered it before. Still, at the time, I did not have any terminology to describe it, and if there is a generally accepted term out there, I am not aware of it. Here is what I propose:
  
 //Nothing-burger-ism// //Nothing-burger-ism//
Line 21: Line 21:
 So, using this new terminology, what I describe above is my realization that JavaCC was (and really still is) a //Nothingburger project//. Not the only one out there by any means, but very much a classic example. I'm sure that many people reading this are nodding their heads because they also have encountered these nothingburgers but maybe (like myself at the time) did not have a term for it. So, using this new terminology, what I describe above is my realization that JavaCC was (and really still is) a //Nothingburger project//. Not the only one out there by any means, but very much a classic example. I'm sure that many people reading this are nodding their heads because they also have encountered these nothingburgers but maybe (like myself at the time) did not have a term for it.
  
-===== Some Telltale Signs of Nothingburger project =====+===== Return to Planet of the Apes? ===== 
 + 
 +It occurred to me recently that there is a science fiction genre that characterizes quite well this nothingburger state of affairs. In a post-apocalyptic, post-industrial future world, human society has mostly devolved to its pre-technological state. However, the landscape is still littered with vestiges of the long-gone industrial civilization. Now, a few old machines are in reasonable state and still work. However, no current-day humans //understand// how they work, much less possess the ability to build such machines. While human society has lost all that knowledge, a few people have figured out how to tinker with a few of these machines and keep them working. Somewhat... What happens now is that these people form a kind of priesthood that wraps their minimal knowledge in a kind of religious mumbo-jumbo. (One unmistakable symptom of //nothingburgerism// is an obsession with formalisms, doing everything according to the //proper procedure//. This could almost be likened to religious rituals.) 
 + 
 +Now, in this scenario, suppose somebody shows up (from the past somehow?) who really has the technical know-how to take these machines apart, fix whatever problem, and put them back together. How is this priesthood going to react? I think it is obvious. They'll express shock that the person is not going about things in the proper manner, following the rituals established by the priesthood. The bottom line is that they are going to obstruct this person's attempt to do anything because it is a challenge to their legitimacy. Finally, one cannot help but notice an eerie similarity with the state of affairs in these nothingburger software projects. The most common pattern by which an open source project becomes a //nothingburger// is that the original author loses interest, drifts away, and none of the people remaining, now the ostensible maintainers, really understand how the code works. So, if people lack the wherewithal to do fundamental work on the core code, then what do they do to justify their continued desired status? It is not hard to see how the //nothingburger// culture or mentality takes form. 
 + 
 +===== Telltale Signs of the Nothingburger project =====
  
   - The project's core code has become a kind of //no-go zone//. What this means is that, if you look at the project's commit record (typically via ''%%git log%%'' nowadays) whatever activity you see there (assuming there is any, but usually there is something or other to look at...) revolves around ancillary things like the build system, maybe updating from Ant to Maven to Gradle... Maybe reorganizing the website... Maybe they correct a spelling mistake in a README file or something...   - The project's core code has become a kind of //no-go zone//. What this means is that, if you look at the project's commit record (typically via ''%%git log%%'' nowadays) whatever activity you see there (assuming there is any, but usually there is something or other to look at...) revolves around ancillary things like the build system, maybe updating from Ant to Maven to Gradle... Maybe reorganizing the website... Maybe they correct a spelling mistake in a README file or something...
Line 28: Line 34:
   - When very minor changes to the code are made, patches that, by the principles of [[https://semver.org|Semantic Versioning]], would only justify a minor point-point release, like 0.7.1 to 0.7.2, they are represented as significant new development. One corollary of this (though this symptom may or may not be present) is that a nothingburger project frequently sports an excessively high version number.   - When very minor changes to the code are made, patches that, by the principles of [[https://semver.org|Semantic Versioning]], would only justify a minor point-point release, like 0.7.1 to 0.7.2, they are represented as significant new development. One corollary of this (though this symptom may or may not be present) is that a nothingburger project frequently sports an excessively high version number.
  
-One could surely list other important symptoms of //nothing-burger-ism//, but they kind of blend in and interact with one another. I think the above points I outline, the first three in particular, are key. Perhaps the first point, this kind of bizarre reverence for the existing codebase is the most reliable sign that a project has devolved into nothing-burger-ism. It is also the characteristic that I myself find the most unsettling, maybe even downright spooky.+One could surely list other important symptoms of //nothing-burger-ism//, but they kind of blend in and interact with one another. I think the above points I outline, the first three in particular, are key. Perhaps the first point, this kind of bizarre reverence for the existing codebase is the most reliable sign that a project has devolved into //nothingburgerism//. It is also the characteristic that I myself find the most unsettling, maybe even downright spooky.
  
-Now, I suppose the most typical pattern by which a software project becomes a nothingburger is that the original author loses interest, drifts away, and none of the people remaining, now the ostensible maintainers, really understand how the code works. So, if people lack the wherewithal to do fundamental work on the core code, then what do they do to justify their continued desired status? And this actually leads naturally to the second point, the culture of extreme fastidiousness. Now, to be clearI do not mean to say that one should not have a certain amount of structure and organization in how one goes about things. Rather, I am talking about a situation where this is all taken to such lengths that it creates a quite mentally oppressive environment. Come to think of it, I am sure that, on occasion, this is a factor in the original author(s) losing interest and abandoning the project! This is actually big topic that I will explore more in a later segment of this Nothingburger series.+At this point, let me be clear about one thing: I do not mean to say that one should not have a certain amount of structure and organization in how one goes about things. Rather, I am talking about a situation where this is all taken to such lengths that it creates a quite mentally oppressive environment. Come to think of it, I am sure that, on occasion, this is a factor in the original author(s) losing interest and abandoning the project! Many things in this life are a question of balance, after all. Yes, a reasonable level of hygiene is a good idea, but what we are talking about here is something more akin to [[https://en.wikipedia.org/wiki/Obsessive–compulsive_disorder|obsessive-compulsive disorder]]. People who suffer from OCD may wash their hands hundreds of times day. They wash their hands and, a minute later, are obssessed with the idea that their hands are dirty, and feel compelled to wash their (quite clean) hands yet againOCD, by the way, is a genuine mental illness and no laughing matter. By the same token, //nothingburgerism// is a psychosocial malaise, and also no joke. (Even if I do crack a few jokes when describing the situation...)
  
-Now, to be clear, a //nothingburger// project is not the same as //abandonware//. Sourceforge and Github are full of orphan projects. However, nobody is trying to hide the state they are in or present them as active. The implicit metaphor in the //nothingburger// terminology implies some attempt at deceit. The //art of the nothingburger// is to present a bun with maybe some lettuce and tomato, a bit of ketchup or mayo, and somehow arrange a //trompe l'oeil// to trick people into thinking that there must be some meat in there. (Some real software development in this case.) But any close inspection reveals that there is no meat in the bun. The other key difference between a nothingburger project and simple abandonware is that the ostensible owners of the nothingburger project will do their level best to prevent anybody from coming in and doing anything. My best best is that in the vast majority of cases, if you approached the owner of some abandonware project on Sourceforge and told him that you would like to pick up the project where he left off and do some work, he would be happy to let you in and have a go at it.+Now, to be clear, a //nothingburger// project is not the same as //abandonware//. Sourceforge and Github are full of orphan projects. However, nobody is trying to hide the state they are in or present them as active. The implicit metaphor in the //nothingburger// terminology implies some attempt at deceit. The //art of the nothingburger// is to present a bun with maybe some lettuce and tomato, a bit of ketchup or mayo, and somehow arrange a //trompe l'oeil// to trick people into thinking that there must be some meat in there. (Some real software development in this case.) But any close inspection reveals that there is no meat in the bun. The other key difference between a nothingburger project and simple abandonware is that the ostensible owners of the nothingburger project will do their level best to prevent anybody from coming in and doing anything. My best bet is that in the vast majority of cases, if you approached the owner of some abandonware project on Sourceforge and told him that you would like to pick up the project where he left off and do some work, he would be happy to let you in and have a go at it.
  
-===== Return to Planet of the Apes=====+Now, as for the other point I mention above, this excessive reverence for "stability" and "backward compatibility", on one level, it could be seen as a transparent rhetorical trick. After all, you always have perfect //stability// and //backward compatibility// by simply doing nothing! So can this ever be considered any sort of great technical achievementIf the competition is over who can be more "stable", the abandonware will win every time!
  
-It occurred to me recently that there is a science fiction genre that characterizes quite well this nothingburger state of affairs. In post-apocalyptic, post-industrial future world, human society has mostly devolved to its pre-technological state. However, the landscape is still littered with vestiges of the long-gone industrial civilization. Nowa few old machines are in reasonable state and still work. Howeverno current-day humans //understand// how they workmuch less possess the ability to build such machines. While human society has lost the all that knowledge, few people have figured out how to tinker with a few of these machines and keep them working. Somewhat... What happens now is that these people form a kind of priesthood that wraps their minimal knowledge in kind of religious mumbo-jumbo. (This relates directly to the second point above about proper procedures and such, that could almost be likened to religious rituals.)+Frankly, I have no more intention of competing with any of these people on //stability// than I do of entering tanning contest with an African to see who can sit in the sun and get blacker! (//Unless the African in question is a Boer from South Africa, in which caseI might consider it!//) Generally speaking, the willingness to enter into rigged competition in which you will always lose is probably about the dictionary definition of a //sucker//, so taking this rhetoric about //stability// very seriously is effectively just a sucker's game.
  
-Nowin this scenario, suppose somebody shows up (from the past somehow?) who really has the technical know-how to take these machines apart, fix whatever problemand put them back together. How is this priesthood going to react? I think it is obvious. They'll express shock that the person is not going about things in the proper mannerfollowing the rituals established by the priesthood. The bottom line is that they are going to obstruct this person's attempt to do anything because it is challenge to their legitimacyThe situation in these nothingburger projects is kind of analogous finally, no?+As for my final point abovethat the extreme overvaluation of minor patches will lead to the nothingburger project having an absurdly high version number, this is a frequent symptom, but not really a //sine qua non// either. However, we do observe it in the legacy JavaCC projectwhich is apparently gearing up for an 8.0 release. The fact of the matter is that, in its 17 years of open source history, that project has not had a level of forward evolution that would correspond to a single point release (0.8 to 0.9 say) by the approximate rules of Semantic Versioning outlined [[https://semver.org/|here]].
  
-(I was trying to recall which science fiction classics have this sort of underlying theme. I vaguely recall one iteration of Planet of the Apes maybe... If somebody would write me and let me know, I would be grateful.)+===== Think of an Army with no Soldiers =====
  
-Now, the next point, this excessive reverence for "stability" and "backward compatibility" is also quite symptomatic of all this. Wellreally, properly understood, it is a rather transparent rhetorical trickAfter all, you always have perfect //stability// and //backward compatibility// by simply doing nothing! So can this ever be considered any sort of great technical achievement? If the competition is over who can be more "stable"the abandonware will win every time!+I have no doubt that there are certain people who will jump at any opportunity to twist and misrepresent what I am saying hereso I feel I have to be very very clear about certain thingsBy no means am I saying here that the //only// thing anybody can do of any value in a software project is write code. In fact, it is frequently the case that the most value that can be added at a given point is by doing things other than coding. For examplemost (pretty much all) open source projects are sorely in need of better documentation than what they have.
  
-FranklyI have no more intention of competing with any of these people on //stability// than I do of entering tanning contest with an African to see who can sit in the sun and get blacker! (//Unless the African in question is a Boer from South Africa, in which case, I might consider it!//) Regardlessthe willingness to enter into a rigged competition in which you will always lose is probably about the dictionary definition of a //sucker//so taking this rhetoric about //stability// very seriously is effectively just a sucker's game.+Howeverthe real issue here is one of balance. Suppose you were journalist assigned to write some articles on the military and you are given access to various people to interview and profile. It turns out that all of these people and, in factevery "soldier" you ever come into contact with has some desk job doing completely sedentary work, typing up reports and such. Also, every last one of these people is of officer rank. Suppose further that when you say you would like to interview some regular soldiersyou are given the runaround and it gradually becomes apparent that there are no regular soldiers to interview.
  
-As for my final point above, that the extreme overvaluation of minor patches will lead to the nothingburger project having an absurdly high version number, this is a frequent symptom, but not really a //sine qua non// either. However, we do observe it in the legacy JavaCC project, which is apparently gearing up for an 8.0 release. The fact of the matter is that, in its 17 years of open source history, that project has not had a level of forward evolution that would correspond to a single point release (0.8 to 0.9 say) by the approximate rules of Semantic Versioning outlined [[https://semver.org/|here]].+//This is an army with all officers and no regular soldiers.//
  
-===== Some Needed Clarification =====+Would that not be completely surreal? How much expertise in military affairs would it take for you to realize that there is something very screwy going on? Of course, we could also imagine a situation where the journalist realizes all this but keeps it to himself, since he realizes that honestly reporting on this absurd state of affairs might be career suicide. In this story, one is not claiming that nobody should be doing any office work. A modern army is a very large bureaucratic organization and it is inevitable that there are lots of personnel engaged in accounting and record keeping and such. However, an army in which every last person has a desk job is an utter absurdity regardless.
  
-Now, before continuing the discussion of //nothingburger-ism// I should make one point clear. By no means am I saying here that the //only// thing anybody can do of any value in a software project is write code. In fact, it is frequently the case that the most value that can be added at given point is by doing things other than coding. For example, most (pretty much all) open source projects are sorely in need of better documentation than what they have.+===== It's fun to be a superhero! =====
  
-Butthe issue nonetheless is one of balance. Suppose you were journalist assigned to write some articles on the militaryIt turns out that every "soldier" you ever come into contact with has some desk job doing completely sedentary worktyping up reports and suchAlsoevery last one of these people is of officer rankSuppose further that when you say you would like to interview some regular soldiersyou are given the runaround and it gradually becomes apparent that there are no regular soldiers to interviewThis is an army with all officers and no regular soldiers.+We could shift that military metaphor a bit and get to another pointwhich is that the stance of people in //nothingburger// project is entirely //defensive//As I pointed out earlierthey have this outrageous, exaggerated fear of changing anything, particularly in the core codeAs I said beforethis led me to think of the future humans in the post-apocalyptic science fiction, who have a completely mysterious, mystical relationship with any of these remaining machineslike the analogy, but I realized at some point that it actually understates the case. You see, the stance of the "priesthood" in that post-apocalyptic science fiction story is not entirely unreasonable. It actually makes sense to be very hesitant to muck with machinery that you don't understandI myself have a somewhat similar relationship with most of the appliances in my home, and I would not mess with them. (Though I am happy to have a qualified repairman to fix my washing machine when it needs fixing.) But the thing is: we're talking about physical machines here....
  
-Would that not be completely surreal? How much expertise in military affairs would it take for you to realize that there is something very screwy going on? Of coursewe could also imagine a situation where the journalist realizes all this but keeps it to himselfsince he realizes that honestly reporting on this absurd state of affairs might be career suicide.+//Softwarecodeis not a **physical** machine.//
  
-Now that I brought up military metaphor, it occurs to me to point out that the stance of the people in a //nothingburger// project is entirely //defensive//They have this outrageous, exaggerated fear of changing anything, particularly in the core code. As I said beforethis led me to think of the future humans in the post-apocalyptic science fiction, who have a completely mysterious, mystical relationship with any of these remaining machines.+If your code is stored in code repository such as GitSVN, or CVS, you can restore it effortlessly to any previous state it was in. I recall on a mailing list hosted by Apache Software Foundation, this whole topic came up. It was about just how conservative the project was in terms of letting people commit codeOne of the people there was making some comparison between allowing people to commit code and trusting your fellow mountain climbers(Apparently, the guy's hobby was rock climbing or something.)
  
-On further thought, however, realized that the stance of that future priesthood is not entirely unreasonable. After allI myself have somewhat similar relationship with most of the appliances in my home, and I would not mess with them. (However, I am happy to have a qualified repairman to fix my washing machine when it needs fixing.) So, all righta person's reluctance to tinker with machinery that they don'really understand is quite understandable. In the case of physical machines...+pointed out to him that the simile would be more applicable ifwhen you fell off cliff at time t, and presumably broke all the bones your bodyyou had the capability of instantly restoring yourself to the state you were in at t-1 just before the fall.
  
-However, the odd thing about this is that software is not a //physical// machine. If your code is stored in a code repository such as GitSVN, or CVS, you can restore it effortlessly to any previous state it was in. So, actually, tinkering with the code is a no-lose situation. I recall on mailing list hosted by Apache Software Foundationthis whole topic came up. It was about just how conservative the project was in terms of letting people commit codeOne of the people there was making some comparison between allowing people to commit code and trusting your fellow mountain climbers. (Apparently, the guy's hobby was rock climbing or something.)+//In essencehacking code is a bit like being superherowho cannot really be hurt, like the Wolverine character in X-men.//
  
-I pointed out to him that the simile would be more applicable if, when you fell off a cliff at time t, and presumably broke all the bones your body, you had the capability of instantly restoring yourself to the state you were in at t-1 just before the fall. (//Geeanother sci-fi fantasy genreX-Men and such...//)+Wolverine can be beatenstabbed and shot and his body just regenerates in short order to the state it was in before. (I grant that Wolverine still feels pain and it can be painful to have to back out your changes and revert to a previous state of the code, but the point is that Wolverine cannot be //permanently// hurtsince his body always just regenerates to its previous state. Similarlyyou can always revert your code to any known working state.)
  
-Thusit is really quite a stretch to liken mucking with source code to a physically dangerous activity like rock climbing. No matter how irreparably you mess up the code, you can always restore it to the previous state anyway. Of course, even if that were not the case, it still would not be comparable to falling off a cliff to one's death! In short, this is one more striking striking example of an argument that is multiple degrees away from making any sense at all!+Sowhat is the agenda of somebody who likens mucking with source code to a physically dangerous activity like rock climbing? If you took the analogy with physically dangerous activities seriously -- rock climbing, deep sea diving, etc-- yes, you would be very cautious about who you would allow to participate in such activities (people need proper training and so forth). Also, you would be right to be extremely fastidious about following all the established safety procedures! If the analogy were correct, the stance of these //nothingburger artists// would actually make some sense! 
 + 
 +//But the analogy with the physically dangerous activity is completely nutso!// 
 + 
 +No matter how irreparably you mess up the code, it can always be restored to the previous state anyway. Regardless, it would still not be comparable to falling off a cliff to one's death! In realitythe argument being made implicitly with this analogy is multiple degrees away from making any sense at all!
  
 This leads us to another frequent symptom of //nothing-burger-ism//: This leads us to another frequent symptom of //nothing-burger-ism//:
Line 70: Line 80:
 //The insiders in a nothingburger project frequently **affect** that they don't understand how version control systems work.// //The insiders in a nothingburger project frequently **affect** that they don't understand how version control systems work.//
  
-The //nothingburger artists// will frequently argue that it is extremely risky to let some "unproven" person (//except how is he supposed to prove himself?//) come in and do anything. Why? They might screw something up. Well, aside from the fact that code stored in a version control system can be restored to any previous known working state, there is also this feature that they all have called //branching//. If somebody shows up and proposes some ideas that you think are dubious, they can be given a separate branch to work on, and have a shot at demonstrating the worth of their ideas.+The //nothingburger artists// will frequently argue that it is extremely risky to let some "unproven" person (//except how is he supposed to prove himself?//) come in and do anything. Why? They might screw something up. Well, aside from the fact that code stored in a version control system can be restored to any previous known working state, there is also this feature that they all have called //branching//. If somebody shows up and proposes some ideas that you think are dubious, they can be given a separate branch to work on, and have a shot at demonstrating the worth of their ideas. What all of this suggests, by the way, is that the correct policy in running an open source project (at least if you want there to be any progress) is:
  
-If you are foolish (or masochistic) enough to be engaging these people in discussion and you point out the above, the typical result is that they simply walk away from the conversation.+  - An extremely aggressive stance in terms of evolving the code forward, refactoring etcetera. (Because if you do some things that turn out to be a bad idea, nothing is lost anyway!) 
 +  - An extremely liberal, open stance towards letting people contribute. (Because newbie contributors can't really do any damage anyway! Especially, if you give them a branch to work on!) 
 + 
 +Of course, a //nothingburger// project is always run 180º away from the above ideas. 
 + 
 +If you are foolish (or masochistic) enough to be engaging these people in discussion and you point out these things, the typical result is that they simply walk away from the conversation. (//One key anti-nothingburger measure must be that you have a culture in which it is **not acceptable** to simply walk away from a conversation. Either you produce a valid counter-argument, or you concede the point at hand.//)
  
 ===== What is to be done? ===== ===== What is to be done? =====
Line 93: Line 108:
 It could well be that a similar answer applies to //nothingburger-ism//. What do you do about an open source project that has devolved into a state of nothingburger-ism? Answer: Don't let your project devolve into nothing-burgerism! It could well be that a similar answer applies to //nothingburger-ism//. What do you do about an open source project that has devolved into a state of nothingburger-ism? Answer: Don't let your project devolve into nothing-burgerism!
  
-Though admittedly, not as absolutely impossible as retrieving one's car keys from the bottom of the ocean, when a once healthy project has lapsed into //nothingburger-ism//, I believe it is extremely hard for it to get out of that state. Now, if nothingburger-ism was a purely //technical// problem, I suppose it would not be so intractable. However, that is not the case. I'm pretty sure that it is primarily non-technical factors that make the situation so impossible -- things best understood in terms of social psychology and such.+Though admittedly, not as absolutely impossible as retrieving one's car keys from the bottom of the ocean, when a once healthy project has lapsed into //nothingburger-ism//, I believe it is extremely hard for it to get out of that state. Now, if nothingburger-ism was a purely //technical// problem, I suppose it would not be so intractable. However, that is not the case. I'm pretty sure that it is primarily non-technical factors that make the situation so impossible -- things best understood in terms of social psychology and such. One problem is: 
 + 
 +===== Passive Acceptance of Illegitimate Authority =====
  
 In any Psychology 101 course, one typically learns about the [[https://en.wikipedia.org/wiki/Milgram_experiment|Milgram experiment]] from nearly 60 years ago. This demonstrated just how conditioned people are to obey anybody that they perceive as an "authority figure". Quite literally, many people will electrically shock somebody to death rather than disobey authority. //Perceived// authority really, since the "authority figure" in the Milgram experiment actually has no real authority over the subject. In any Psychology 101 course, one typically learns about the [[https://en.wikipedia.org/wiki/Milgram_experiment|Milgram experiment]] from nearly 60 years ago. This demonstrated just how conditioned people are to obey anybody that they perceive as an "authority figure". Quite literally, many people will electrically shock somebody to death rather than disobey authority. //Perceived// authority really, since the "authority figure" in the Milgram experiment actually has no real authority over the subject.