4 ms·

Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network e

Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here. This library is not going to divert much (any?) effort that could have improved other date-time libraries.

__jal 10y ago
Exactly. This isn't X.org. The author has an itch to scratch, and scratched it in exactly the right way. Trying to funnel someone with an itch into a project is a bit like making someone on meth fill out paperwork: kills the buzz and works out poorly. And if just one human understands the nightmare of date handling a bit better, it is a positive thing for the humans.
sametmax 10y ago
If you contribute to any open source project, you quickly learn code is only a small (yet important) part of the effort. Other stuff that are splitted: - attention; - visibility; - pull requests; - documentation edits; - bug reports; - installs (and hence testing on the field); - compatibility layers; - compatible tooling; - 3rd party tutorials, snippets and examples; - help from integrators; Now if you don't have any very good alternatives, it's good : you want to steal that from them. But when you DO have good existing projects, then those are the bread and butter of their success. Now I know it's way harder to contribute to something than roll you own. I know that's it's also more fun to roll your own. And there is the ego at play as well. I understand all that, and I respect Kenneth as a professional. But I don't think it's a good call on his part here. It is espacially true for him, because he now have such a good rep in the Python community that everything he does get under the spotlight.
- jsnathan 10y ago
  Have a look at the code [1]. There's maybe 20 lines of actual logic in there. Even taking all of what you mentioned into account, it's still not more than a single afternoon. I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that. [1]: https://github.com/kennethreitz/maya/blob/master/maya.py https://github.com/kennethreitz/maya/blob/master/maya.py

__jal 10y ago

Exactly. This isn't X.org. The author has an itch to scratch, and scratched it in exactly the right way. Trying to funnel someone with an itch into a project is a bit like making someone on meth fill out paperwork: kills the buzz and works out poorly. And if just one human understands the nightmare of date handling a bit better, it is a positive thing for the humans.

sametmax 10y ago

If you contribute to any open source project, you quickly learn code is only a small (yet important) part of the effort. Other stuff that are splitted: - attention; - visibility; - pull requests; - documentation edits; - bug reports; - installs (and hence testing on the field); - compatibility layers; - compatible tooling; - 3rd party tutorials, snippets and examples; - help from integrators; Now if you don't have any very good alternatives, it's good : you want to steal that from them. But when you DO have good existing projects, then those are the bread and butter of their success. Now I know it's way harder to contribute to something than roll you own. I know that's it's also more fun to roll your own. And there is the ego at play as well. I understand all that, and I respect Kenneth as a professional. But I don't think it's a good call on his part here. It is espacially true for him, because he now have such a good rep in the Python community that everything he does get under the spotlight.

jsnathan 10y ago
Have a look at the code [1]. There's maybe 20 lines of actual logic in there. Even taking all of what you mentioned into account, it's still not more than a single afternoon. I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that. [1]: https://github.com/kennethreitz/maya/blob/master/maya.py https://github.com/kennethreitz/maya/blob/master/maya.py