4 ms·

We need a term like “Mature” or similar for dependencies that are done. Mature dependencies have two characteristics: 1. Well defined scope 2. Infrequent chan

We need a term like “Mature” or similar for dependencies that are done. Mature dependencies have two characteristics: 1. Well defined scope 2. Infrequent changes Nomad has many of these (msgpack, envparse, cli, etc). These dependencies go years without changing so the dependency management burden rapidly approaches zero. This is an especially useful property for “leaf” dependencies with no dependencies of their own. I wish libraries could advertise their intent to be Mature. I’d choose a Mature protobuf library over one that constantly tweaked its ergonomics and performance. Continual iterative improvement is often a boon, but sometimes it’s not worth the cost.

delusional 1y ago
I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.
- schmichael 1y ago
  A great point! All of the libraries I mentioned are created and maintained by corporations. Hobbyists, as always, are free to do as they please without judgement from me. :) I will say I get great satisfaction from the little envparse library I wrote needing near-0 maintenance. It’s a rare treat to be able to consider any project truly done.
- procaryote 1y ago
  Isn't that an argument _for_ having a "mature" label? To avoid the hobbyists who have no intention to maintain their thing? Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for
  - deleted 1y ago
    [deleted]
  - delusional 1y ago
    > Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for There certainly are. I would never say to disregard anything because it was a hobby project. You just don't get to expect it being that way. My basic point is that a hobby project can never take responsibility. If you have a support contract you are allowed to have some expectation of support. If you do not, then no expectation is warranted and everything you get is a gift. A "mature" label carries the same problem. You are expecting the author to label something for you. That's work. If you're pulling from the commons, you must respect that people can label stuff whatever they like, and unmotivated blanket lies are not illegal.
    - procaryote 1y ago
      yeah, that's a good point
- pclmulqdq 1y ago
  > I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. Nobody is asking for professional quality standards from hobby projects. At best, they are asking for hobby projects to advertise themselves as such, and not as "this is a library for [x] that you can use in your stuff with the expectations of [maintenance/performance/compatibility/etc.]." Resume-driven development seems to cause people to oversell their hobby projects as software that is ready to have external users. > If you want a mature protobuf implementation you should probably buy one No software is ever developed this way. For some reason, libraries are always free. Approximately nobody will buy paid libraries.
  - jeffparsons 1y ago
    > For some reason, libraries are always free. Approximately nobody will buy paid libraries. I suspect this is in no small part because figuring out a licensing (edit: pricing!) model that is both appealing to consumers and sustainable for authors is damn near impossible.
  - delusional 1y ago
    > At best, they are asking for hobby projects to advertise themselves as such That's also work. You don't get to ask the hobby programmer to do your work of vetting serious/maintained projects for you. As the professional with a job, you have to do that. If some rando on GitHub writes in their readme that it's maintained, but lies. You're the idiot for believing him. He's probably 12 years old, and you're supposedly a professional. > No software is ever developed this way. That's just inaccurate. In my day job we pay for at least 3-4 3rd party libraries that we either have support contracts on or that were developed for us along with a support contract. Besides those there's also the myriad of software products, databases, editors, Prometheus, grafana, that we pay for. Software people really underestimate how much business guys are willing to pay for having somebody to call. It's not "infinitely scalable" in the way VC's love, but it's definitely a huge business opportunity.
    - caspar 1y ago
      To add to this, in the gamedev space there are a bunch of middleware libraries that are commonly paid for: fmod/wwise, multiplayer networking sdks, etc.
procaryote 1y ago
Java did this sometimes by essentially adding slightly tidied up versions of whatever was the de-facto standard to the standard library. Java 1.3 didn't have regexes but most people were using the same apache commons thing, so java 1.4 added regexes that looked exactly like that. Java's date handling was a pain so people mostly used joda-date; a later java version added something that mostly works like jodadate. Etc. It is an easy way to get a somewhat OK standard library as the things you add became popular on their own merits at some point. Once added, the lowest friction path is to just use the standard library; and as it is the standard library you have a slightly better hope someone will care to maintain it. You can still build a better one if needed for your use-case, but the batteries are included for basic usage
sethops1 1y ago
I feel like the Go ecosystem almost serendipitously has this built in - modules marked v0.X.Y being immature and under development, and v1 or greater being mature, keeping changes mostly down to bug fixes. I think some folks may even follow this convention!

delusional 1y ago

I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.

schmichael 1y ago
A great point! All of the libraries I mentioned are created and maintained by corporations. Hobbyists, as always, are free to do as they please without judgement from me. :) I will say I get great satisfaction from the little envparse library I wrote needing near-0 maintenance. It’s a rare treat to be able to consider any project truly done.
procaryote 1y ago
Isn't that an argument _for_ having a "mature" label? To avoid the hobbyists who have no intention to maintain their thing? Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for
- deleted 1y ago
  [deleted]
- delusional 1y ago
  > Also there are lots of lovely projects maintained at high levels by hobbyists, and plenty of abandonware that was at some point paid for There certainly are. I would never say to disregard anything because it was a hobby project. You just don't get to expect it being that way. My basic point is that a hobby project can never take responsibility. If you have a support contract you are allowed to have some expectation of support. If you do not, then no expectation is warranted and everything you get is a gift. A "mature" label carries the same problem. You are expecting the author to label something for you. That's work. If you're pulling from the commons, you must respect that people can label stuff whatever they like, and unmotivated blanket lies are not illegal.
  - procaryote 1y ago
    yeah, that's a good point
pclmulqdq 1y ago
> I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. Nobody is asking for professional quality standards from hobby projects. At best, they are asking for hobby projects to advertise themselves as such, and not as "this is a library for [x] that you can use in your stuff with the expectations of [maintenance/performance/compatibility/etc.]." Resume-driven development seems to cause people to oversell their hobby projects as software that is ready to have external users. > If you want a mature protobuf implementation you should probably buy one No software is ever developed this way. For some reason, libraries are always free. Approximately nobody will buy paid libraries.
- jeffparsons 1y ago
  > For some reason, libraries are always free. Approximately nobody will buy paid libraries. I suspect this is in no small part because figuring out a licensing (edit: pricing!) model that is both appealing to consumers and sustainable for authors is damn near impossible.
- delusional 1y ago
  > At best, they are asking for hobby projects to advertise themselves as such That's also work. You don't get to ask the hobby programmer to do your work of vetting serious/maintained projects for you. As the professional with a job, you have to do that. If some rando on GitHub writes in their readme that it's maintained, but lies. You're the idiot for believing him. He's probably 12 years old, and you're supposedly a professional. > No software is ever developed this way. That's just inaccurate. In my day job we pay for at least 3-4 3rd party libraries that we either have support contracts on or that were developed for us along with a support contract. Besides those there's also the myriad of software products, databases, editors, Prometheus, grafana, that we pay for. Software people really underestimate how much business guys are willing to pay for having somebody to call. It's not "infinitely scalable" in the way VC's love, but it's definitely a huge business opportunity.
  - caspar 1y ago
    To add to this, in the gamedev space there are a bunch of middleware libraries that are commonly paid for: fmod/wwise, multiplayer networking sdks, etc.

procaryote 1y ago

Java did this sometimes by essentially adding slightly tidied up versions of whatever was the de-facto standard to the standard library. Java 1.3 didn't have regexes but most people were using the same apache commons thing, so java 1.4 added regexes that looked exactly like that. Java's date handling was a pain so people mostly used joda-date; a later java version added something that mostly works like jodadate. Etc. It is an easy way to get a somewhat OK standard library as the things you add became popular on their own merits at some point. Once added, the lowest friction path is to just use the standard library; and as it is the standard library you have a slightly better hope someone will care to maintain it. You can still build a better one if needed for your use-case, but the batteries are included for basic usage

sethops1 1y ago

I feel like the Go ecosystem almost serendipitously has this built in - modules marked v0.X.Y being immature and under development, and v1 or greater being mature, keeping changes mostly down to bug fixes. I think some folks may even follow this convention!