3 ms·

One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintai

by n0us 10y ago

One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing. The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fix some obviously horrible bug because it's a 'feature', or abandoning the project for months at a time, often there is a cop out mentality that goes along the lines of "well it's my project and I didn't guarantee anything when you decided to use it so why don't you go make your own." There by taking credit for the project's successes but not responsibility for it's failures. So then people do go and write their own implementations and we end up with half a dozen half baked libraries. An Example: Underscore and lodash are both very good, so are not examples of half-baked, but do we really need both of them? People will just say "well you only have to use one in your app... yada yada yada" but the problem is that if I want to rely on any other npm packages in my app, are they using lodash or underscore? I'll probably just end up with both of them shipping in the bundle because for whatever reason there couldn't just be one popular utility library, there had to be two that do basically the same thing. People will respond to this and say "well why don't you fork those modules that rely on underscore and make them use lodash?" My answer is no. I don't want to fork stuff. I just want to be able to find modules that I can rely on with a reasonable expectation of quality and maintenance. I'll even help maintain if it doesn't seem completely futile. There may be some advantages of lodash over underscore in comparison to one another but those advantages are minor in comparison to what would be gained by having a single utility library that everyone is on board with. Don't even get me started with routing libraries for React.

Bahamut 10y ago
Most open source maintainers are developers who work full time - I am a maintainer of a major project, but there are times my activity is light, such as the past two months. In that time, I travelled to Salt Lake City, Reno, Portland, San Diego, Seattle, and now in route to Chicago - I ran a half and full marathon in that time, and about to run another half tomorrow morning. I am currently in crunch time at my current job for the past two weeks, and I am about to leave for a well earned 2 1/2 week vacation to England, France, Switzerland, and Italy. I don't plan on coding much, if at all, while in Europe. I very much enjoy working on open source, and have implemented some tricky but highly useful features over the past almost 1 1/2 years of my stewardship that users greatly appreciate. However, I also have a rich life outside of development as well, and I believe that each persons' choices with how they choose to use their time should be respected. If you are not paying or contributing your own time feature developing or assisting maintainance, complaining about maintainer absence is really poor. We are not on demand tech support.
- StevePerkins 10y ago
  In the Java world, most major open source projects are sponsored by companies. Someone(s) is getting paid to maintain and evolve that thing as part of their job. Companies might do this to drive traffic toward the commercial "enterprise" version, for which they charge money. More commonly though, it's just something that they use internally... and they open it up for marketing/prestige/recruitment purposes. In most other language ecosystems, most open source projects tend to be driven by individuals as unpaid side projects. That's great in a certain sense, and a large part of the reason why Java is less "cool" among young people who are eager to plant their own flag on an open source thing. But sadly, it's just really difficult to keep a major side project alive and healthy over the long-term without sponsorship. So those ecosystems tend to be chaotic and flaky.
  - n0us 10y ago
    Couldn't have said it better. In the webdev world this turns into a problem because I need to rely on these oss projects and while some of them might be high quality, there is a significant overhead involved in determining which ones are worth using and which ones I can rely on. For personal projects it's a not big deal but for work I want to be as efficient and reliable as possible and the chaotic/flaky ecosystem gets in the way. edit: fixed to *not a big deal
agnivade 10y ago
Not sure, whether you saw this or not. But there has been some effort on this front - https://github.com/jashkenas/underscore/issues/2182 https://github.com/jashkenas/underscore/issues/2182

by n0us 10y ago

Bahamut 10y ago

Most open source maintainers are developers who work full time - I am a maintainer of a major project, but there are times my activity is light, such as the past two months. In that time, I travelled to Salt Lake City, Reno, Portland, San Diego, Seattle, and now in route to Chicago - I ran a half and full marathon in that time, and about to run another half tomorrow morning. I am currently in crunch time at my current job for the past two weeks, and I am about to leave for a well earned 2 1/2 week vacation to England, France, Switzerland, and Italy. I don't plan on coding much, if at all, while in Europe. I very much enjoy working on open source, and have implemented some tricky but highly useful features over the past almost 1 1/2 years of my stewardship that users greatly appreciate. However, I also have a rich life outside of development as well, and I believe that each persons' choices with how they choose to use their time should be respected. If you are not paying or contributing your own time feature developing or assisting maintainance, complaining about maintainer absence is really poor. We are not on demand tech support.

StevePerkins 10y ago
In the Java world, most major open source projects are sponsored by companies. Someone(s) is getting paid to maintain and evolve that thing as part of their job. Companies might do this to drive traffic toward the commercial "enterprise" version, for which they charge money. More commonly though, it's just something that they use internally... and they open it up for marketing/prestige/recruitment purposes. In most other language ecosystems, most open source projects tend to be driven by individuals as unpaid side projects. That's great in a certain sense, and a large part of the reason why Java is less "cool" among young people who are eager to plant their own flag on an open source thing. But sadly, it's just really difficult to keep a major side project alive and healthy over the long-term without sponsorship. So those ecosystems tend to be chaotic and flaky.
- n0us 10y ago
  Couldn't have said it better. In the webdev world this turns into a problem because I need to rely on these oss projects and while some of them might be high quality, there is a significant overhead involved in determining which ones are worth using and which ones I can rely on. For personal projects it's a not big deal but for work I want to be as efficient and reliable as possible and the chaotic/flaky ecosystem gets in the way. edit: fixed to *not a big deal

agnivade 10y ago

Not sure, whether you saw this or not. But there has been some effort on this front - https://github.com/jashkenas/underscore/issues/2182 https://github.com/jashkenas/underscore/issues/2182