4 ms·

You make it sound like GitHub being a graveyard is a bad thing. Does this mean that you rather had Croniter not exist at all? It is simple, you see a project y

by tinco 14y ago

You make it sound like GitHub being a graveyard is a bad thing. Does this mean that you rather had Croniter not exist at all? It is simple, you see a project you like. If it has a bug you fix it in a fork. You use the fork until the project lead responds to your pull request. And if the project leads response doesn't suit you, you just continue to use the fork, you can pull from the original project whenever you like.

IgorPartola 14y ago
I guess I did make it sound like that. It is frustrating to find a project that on the surface works, but under the hood has issues all over the place. However, you are right, it is good that the project exists in the first place. Otherwise, I would have spent a day instead of an hour trying to solve my problem. The issue I have is with project ownership. Forking a project is great. That's why there are 14 forks of Croniter. The issue is that when there are two divergent forks, it is not easy to tell what's going on. When a useful project gets abandoned, we typically don't have a way to deal with the consequences. Your method of forking and pulling changes only works if I am making really minor changes. However, if my changes conflict with the upstream in a major way (say I went about solving a design flaw differently than the newly awoken upstream author), I cannot proceed. Now if I want to use the upstream version I have to re-write my own software. Or I could continue with my own version, but without the benefit of upstream. Both choices are evil. Instead, perhaps a good way to say "I officially abandon this project. Someone please inherit it." would be good. This could be done at GitHub level, where if I search for croniter I could get a suggestion for "Did you mean this fork of croniter that is significantly more active?" The issue is that then I want to install the code via PyPI, Ruby gems, etc. and the same problem arises there.
- akkartik 14y ago
  I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was going through my life fine without it, and seeing the project made me try it out[1]. Then one can feel sucked in if it mis-sets expectations. Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide. [1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062 https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.
  - IgorPartola 14y ago
    I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes. But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot. The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver: c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates) (The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.) The above is an issue that's bitten many people, yet everyone continues using MySQLdb.
danielweber 14y ago
As a community, I think we need to do more encouraging people to do "pick up and fix the existing project for thing X" rather than "build a brand new project for thing X." Right now it's much sexier to do the latter -- hey, you might have the next RubyonRails!
- IgorPartola 14y ago
  Hasn't it always been much sexier to invent your own thing? I agree, picking up existing projects should be encouraged. The problems with this approach are: 1. The original owner is not there to give you commit access, so you have to fork the project. This means that if the project had some number of users you cannot bring them with you. Imagine if there was a better version of Django out there, made by a group of talented hackers but you never heard about it because GitHub never told you that out of 1,500+ forks of Django one is really pretty awesome and actively developed. 2. The original owner is not there to give you access to distributing the software. This means that even if you create and maintain a fork of the original project, you now have to distribute it under a different name, once again losing popularity to the "standard" version. Don't get me wrong, I'm not advocating that if a project is abandoned it be given to the next runner up automatically. The above issues also serve as a negative feedback loop preventing all sorts of bad software from cropping up. It just means that large projects like ImageMagick can effectively become zombies. You develop your code against them, then realize they are no good and have to re-write your code against a fork or evolution of that project.

by tinco 14y ago

IgorPartola 14y ago

I guess I did make it sound like that. It is frustrating to find a project that on the surface works, but under the hood has issues all over the place. However, you are right, it is good that the project exists in the first place. Otherwise, I would have spent a day instead of an hour trying to solve my problem. The issue I have is with project ownership. Forking a project is great. That's why there are 14 forks of Croniter. The issue is that when there are two divergent forks, it is not easy to tell what's going on. When a useful project gets abandoned, we typically don't have a way to deal with the consequences. Your method of forking and pulling changes only works if I am making really minor changes. However, if my changes conflict with the upstream in a major way (say I went about solving a design flaw differently than the newly awoken upstream author), I cannot proceed. Now if I want to use the upstream version I have to re-write my own software. Or I could continue with my own version, but without the benefit of upstream. Both choices are evil. Instead, perhaps a good way to say "I officially abandon this project. Someone please inherit it." would be good. This could be done at GitHub level, where if I search for croniter I could get a suggestion for "Did you mean this fork of croniter that is significantly more active?" The issue is that then I want to install the code via PyPI, Ruby gems, etc. and the same problem arises there.

akkartik 14y ago
I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was going through my life fine without it, and seeing the project made me try it out[1]. Then one can feel sucked in if it mis-sets expectations. Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide. [1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062 https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.
- IgorPartola 14y ago
  I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes. But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot. The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver: c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates) (The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.) The above is an issue that's bitten many people, yet everyone continues using MySQLdb.

danielweber 14y ago

As a community, I think we need to do more encouraging people to do "pick up and fix the existing project for thing X" rather than "build a brand new project for thing X." Right now it's much sexier to do the latter -- hey, you might have the next RubyonRails!

IgorPartola 14y ago
Hasn't it always been much sexier to invent your own thing? I agree, picking up existing projects should be encouraged. The problems with this approach are: 1. The original owner is not there to give you commit access, so you have to fork the project. This means that if the project had some number of users you cannot bring them with you. Imagine if there was a better version of Django out there, made by a group of talented hackers but you never heard about it because GitHub never told you that out of 1,500+ forks of Django one is really pretty awesome and actively developed. 2. The original owner is not there to give you access to distributing the software. This means that even if you create and maintain a fork of the original project, you now have to distribute it under a different name, once again losing popularity to the "standard" version. Don't get me wrong, I'm not advocating that if a project is abandoned it be given to the next runner up automatically. The above issues also serve as a negative feedback loop preventing all sorts of bad software from cropping up. It just means that large projects like ImageMagick can effectively become zombies. You develop your code against them, then realize they are no good and have to re-write your code against a fork or evolution of that project.