6 ms·

And we're still stuck on 1.4.2! Surprisingly difficult getting rid of older versions if your plugins all depend on an old version... we've got to rewrite 4 plu

And we're still stuck on 1.4.2! Surprisingly difficult getting rid of older versions if your plugins all depend on an old version... we've got to rewrite 4 plugins due to API breaks to get anywhere near this version. Will never import any community plugins again. jQuery and jQuery UI only.

acdha 13y ago
“community” doesn't mean a large volunteer workforce. If you're using those plugins, why not work with the upstream to fix compatibility?
- csmithuk 13y ago
  Most of them are abandoned and have restrictive licenses so you're SOL then.
  - fletchowns 13y ago
    How solid did the projects look when you originally started using them?
    - csmithuk 13y ago
      Very. Multiple updates, public contact addresses, good reviews.
      - oneeyedpigeon 13y ago
        Can you give some examples? Might be useful to know what to look out for.
  - jrochkind1 13y ago
    This is a hazard of open source or shared community code in general, I think most of us have run into -- and more will be as history moves forward, more years and more projects means more abandoned projects, and more dependency changes meaning abandoned projects become liabilities. To some extent there's not much you can do, the risk is just part of the game; you're making a tradeoff, risking future lock-in to abandonware, by gaining produtivity by using someone elses shared code. But the one thing you CAN do is avoid using projects with restrictive licenses. It takes something pretty exceptional ly valuable (AND with all the signs of being a project with legs) to get me to use something with a restrictive license. If it's got a sufficiently flexible license AND is popular, it's pretty likely someone (if not me) is going to step in to do the bare minimum of changes neccessary for security or dependency upgrades. The other thing one can do is try not to use projects with really poorly written/organized code -- cause it's an additional barrier to someone else patching it once it's abandonware. But that's harder to judge correctly, and anyway if the thing is really useful and difficult for me to reinvent myself, I'm likely to ignore perceived bad code quality and use it anyway.
    - jmulho 13y ago
      > But the one thing you CAN do is avoid using projects with restrictive licenses. Could you provide some rules of thumb for how to quickly "avoid using projects with restrictive licenses" (short of getting a law degree). I assume there are a handful of popular licenses that you just know are what you are looking for (e.g. BSD, Apache, GPL2, or something) and you look for that. Otherwise you scan for specific restrictive or unrestrictive verbage. For the uninitiated, could you explain what you are looking for?
      - acdha 13y ago
        That'd be it exactly: if it's not e.g. {BSD,Apache,GPLv3,CC0} think carefully before using it. If they haven't picked a license, email first and ask – if they can't pick a license, it's not a serious project.

acdha 13y ago

“community” doesn't mean a large volunteer workforce. If you're using those plugins, why not work with the upstream to fix compatibility?

csmithuk 13y ago
Most of them are abandoned and have restrictive licenses so you're SOL then.
- fletchowns 13y ago
  How solid did the projects look when you originally started using them?
  - csmithuk 13y ago
    Very. Multiple updates, public contact addresses, good reviews.
    - oneeyedpigeon 13y ago
      Can you give some examples? Might be useful to know what to look out for.
- jrochkind1 13y ago
  This is a hazard of open source or shared community code in general, I think most of us have run into -- and more will be as history moves forward, more years and more projects means more abandoned projects, and more dependency changes meaning abandoned projects become liabilities. To some extent there's not much you can do, the risk is just part of the game; you're making a tradeoff, risking future lock-in to abandonware, by gaining produtivity by using someone elses shared code. But the one thing you CAN do is avoid using projects with restrictive licenses. It takes something pretty exceptional ly valuable (AND with all the signs of being a project with legs) to get me to use something with a restrictive license. If it's got a sufficiently flexible license AND is popular, it's pretty likely someone (if not me) is going to step in to do the bare minimum of changes neccessary for security or dependency upgrades. The other thing one can do is try not to use projects with really poorly written/organized code -- cause it's an additional barrier to someone else patching it once it's abandonware. But that's harder to judge correctly, and anyway if the thing is really useful and difficult for me to reinvent myself, I'm likely to ignore perceived bad code quality and use it anyway.
  - jmulho 13y ago
    > But the one thing you CAN do is avoid using projects with restrictive licenses. Could you provide some rules of thumb for how to quickly "avoid using projects with restrictive licenses" (short of getting a law degree). I assume there are a handful of popular licenses that you just know are what you are looking for (e.g. BSD, Apache, GPL2, or something) and you look for that. Otherwise you scan for specific restrictive or unrestrictive verbage. For the uninitiated, could you explain what you are looking for?
    - acdha 13y ago
      That'd be it exactly: if it's not e.g. {BSD,Apache,GPLv3,CC0} think carefully before using it. If they haven't picked a license, email first and ask – if they can't pick a license, it's not a serious project.