how do you pick the right libraries?

[12345678]

often there are multiple libraries that do the same work, both are active, both also have good licenses, in such cases how do you pick one?

 

you do just randomly pick one or what?

[Slottr]

Read the documentation and choose which appeals to your project structure the best.

All will be good and bad for different reasons

[ramava]

1 minute ago, Slottr said:

Read the documentation and choose which appeals to your project structure the best.

All will be good and bad for different reasons

Also, you may discover the documentation for one or another is just awful and you won't want to deal with it. I've encountered that a few times.

[vorticalbox]

I code mostly in nodejs, other then express/mongoose for our stack I just jump to using ramda [0] and that lets me build pretty much what ever i need

 

[0]  https://ramdajs.com/docs/

 

 

[Eigenvektor]

Aside from the documentation (and its quality), look at the number of people using the library, the number of issues on GitHub (or wherever it is hosted), how they respond to issues, what their release cadence is. Maybe look at how many topics you can find on places like Stackoverflow and what they are about (people having issues, encountering bugs, questions being answered etc.)

 

I'd go with the library that is more widely used, has fewer issues (or are at least resolved quickly) and is well documented.

 

~edit: Also have a look at its developer(s). A project with a lone developer is much more likely to die or run into issues than a library backed by a community/team or company and/or used by lots of big projects.

[Franck]

If they do the same thing my list of parameters for selection goes in that order:

 

1 - If I end the license can I still use the last version I had access to. If the answer is no then bye bye.

2 - If company close it must have an escrow service or be open source at least.

3 - Does it have good support with relatively good response time. Anything under 24 hrs is respectable.

4 - Is the documentation readable or even present at least

5 - Do they have other library that the competition do not that down the line I might get into.

 

[Dat Guy]

1 hour ago, Eigenvektor said:

I'd go with the library that is more widely used

I, personally, prefer libraries which have a sane license (GNU licenses won't fit my own software) and come with as little overhead as possible, even if only three people use it.

Naturally, if I find a bug myself, I'll report it.

[Eigenvektor]

37 minutes ago, Dat Guy said:

I, personally, prefer libraries which have a sane license (GNU licenses won't fit my own software) and come with as little overhead as possible, even if only three people use it.

Naturally, if I find a bug myself, I'll report it.

Sure. Where I work this is an issue as well. We can't use GPL libraries in our code. But using a library from a lone developer that is only used by three people can easily become a liability as well. There's a good change it might be abandoned and/or isn't well tested and maintained to begin with.

 

A library that is widely used, has good documentation and good test coverage is definitely preferable. It is less likely to become a source of bugs and its interface is most likely mature and stable and won't experience breaking changes with every release.

 

An active community and companies invested in its continued existence also means it is less likely to be abandoned a year down the line where you now either have to start maintaining it yourself or find a replacement. Less of an issue for a personal project, but it's a different matter in a professional environment.

[Dat Guy]

I made the experience that seemingly "unmaintained" software tends to be "good enough" (as in: won't need updates every week), while "maintained" libraries break their APIs more often than not.

[Franck]

14 hours ago, Dat Guy said:

I made the experience that seemingly "unmaintained" software tends to be "good enough" (as in: won't need updates every week), while "maintained" libraries break their APIs more often than not.

I agree that as long as it's not a critical application and that it rarely changes it is acceptable. When you have contract liability with gov or you live in a production environment that's another story.

[straight_stewie]

On 6/2/2021 at 2:28 PM, Dat Guy said:

sane license (GNU licenses won't fit my own software)

Well, one could argue that the GPL is not sane unless you are in the universe of GNU tools.

[Alexeygridnev1993]

On 6/2/2021 at 10:45 PM, Eigenvektor said:

Sure. Where I work this is an issue as well. We can't use GPL libraries in our code. But using a library from a lone developer that is only used by three people can easily become a liability as well. There's a good change it might be abandoned and/or isn't well tested and maintained to begin with.

 

A library that is widely used, has good documentation and good test coverage is definitely preferable. It is less likely to become a source of bugs and its interface is most likely mature and stable and won't experience breaking changes with every release.

 

An active community and companies invested in its continued existence also means it is less likely to be abandoned a year down the line where you now either have to start maintaining it yourself or find a replacement. Less of an issue for a personal project, but it's a different matter in a professional environment.

As long as you're not modifying those GPL-ed libraries, isn't it OK to still use them in proprietary projects?

[Eigenvektor]

5 hours ago, Alexeygridnev1993 said:

As long as you're not modifying those GPL-ed libraries, isn't it OK to still use them in proprietary projects?

No. You can't use code that is GPL licensed in proprietary software, without making that software GPL licensed as well. Which is why it is often considered a "viral" license.

 

There's the LGPL, which allows you to link static binaries into your code even if that code is "non-free", but you can't use them in source form. Which means you can't modify them if e.g. you discover a bug, so you have to wait on the original developer to fix it (if they are still around). Which is also not an ideal situation.

 

Any company I've ever worked with has stayed the hell away from touching anything (L)GPL. No business wants to risk having to make their product open source involuntarily. In fact, some of our customers have insisted on contracts that explicitly forbid us from ever using GPL licensed code in products we developed on their behalf.

[Alexeygridnev1993]

2 hours ago, Eigenvektor said:

No. You can't use code that is GPL licensed in proprietary software, without making that software GPL licensed as well. Which is why it is often considered a "viral" license.

 

There's the LGPL, which allows you to link static binaries into your code even if that code is "non-free", but you can't use them in source form. Which means you can't modify them if e.g. you discover a bug, so you have to wait on the original developer to fix it (if they are still around). Which is also not an ideal situation.

 

Any company I've ever worked with has stayed the hell away from touching anything (L)GPL. No business wants to risk having to make their product open source involuntarily. In fact, some of our customers have insisted on contracts that explicitly forbid us from ever using GPL licensed code in products we developed on their behalf.

Alright. Then, how, for example, can there be proprietary Linux drivers? Nvidia does it, as well as all Android phones manufacturers, even though the drivers are part of the kernel on Linux, and Linux is GPL2-only. I don't doubt what you're saying about company policies, but, maybe, companies are just being extra careful?

[trag1c]

2 hours ago, Eigenvektor said:

No. You can't use code that is GPL licensed in proprietary software, without making that software GPL licensed as well. Which is why it is often considered a "viral" license.

 

There's the LGPL, which allows you to link static binaries into your code even if that code is "non-free", but you can't use them in source form. Which means you can't modify them if e.g. you discover a bug, so you have to wait on the original developer to fix it (if they are still around). Which is also not an ideal situation.

 

Any company I've ever worked with has stayed the hell away from touching anything (L)GPL. No business wants to risk having to make their product open source involuntarily. In fact, some of our customers have insisted on contracts that explicitly forbid us from ever using GPL licensed code in products we developed on their behalf.

I could be totally wrong on this but I thought if you dynamically linked them you only have to release the modifications to the library and not your whole source. I've done a fair bit of software development but nothing "professional" or commercial so I haven't paid too much attention to software licenses in the past. I will probably run into this in a couple years time once I finish my schooling and finally switch gears to a software developer lol.

[Eigenvektor]

38 minutes ago, trag1c said:

I could be totally wrong on this but I thought if you dynamically linked them you only have to release the modifications to the library and not your whole source.

I'm neither a lawyer and nor a specialist on software licenses. I've discussed this with other people in the past and more often than not you end up with as many opinions as there are people involved. But it's just an opinion after all.

 

A lawyer will give your their professional opinion and (depending on how much you pay) more or less well reasoned arguments you could use in court. But neither will they give you any guarantees nor can they protect you from getting sued. Which is not something companies want to risk, because lawsuits are expensive even if you're ultimately in the right.

 

This kind of uncertainty is what keeps most companies well away from anything "tainted" by the GPL. Why risk it as long as there are equivalent libraries available that have less restrictive or potentially costly licenses?

 

38 minutes ago, Alexeygridnev1993 said:

Alright. Then, how, for example, can there be proprietary Linux drivers? Nvidia does it, as well as all Android phones manufacturers, even though the drivers are part of the kernel on Linux, and Linux is GPL2-only. I don't doubt what you're saying about company policies, but, maybe, companies are just being extra careful?

I'm not sure how it works exactly, but I think the proprietary part of the driver is not part of the kernel nor does it reference or build on any kernel code. Instead you have a small open source part in the kernel, which then communicates with the closed part of the driver. So the opposite of using an open source library.

 

And yes, companies are being extra careful. Why risk a potentially costly lawsuit if you don't have to.

 

~edit: Just found a quote:

Quote

The Linux kernel itself is all free software, distributed under the GNU General Public License. Third parties may distribute closed-source drivers in the form of loadable kernel modules. There's some debate as to whether the GPL allows them; Linus Torvalds has decreed that proprietary modules are allowed.

So not really part of the kernel but as you can see there's still debate around it.