Obligation to maintain and support add-ons

General Forums Blender and CG Discussions
1

Commonly add-ons take one-time payments from customers.
Is the developer expected or required to support the add-on indefinitely? in 1 year’s time? 5 years?

If there is a point at which it is no longer worth doing the support?

is the developer free to choose to not update an add-on or not answer emails?

I am especially looking to hear from any add-on developers.

2

It depends on if the add-on developer cares about having a good relationship with customers. I do, so I reply to all emails I get about my add-ons and keep them updated with the most current version of Blender. There’s no obligation to do so, there’s no law that says software has to be updated every so often, but I find it’s a good idea to treat current customers as if they’re just as important as future customers :slight_smile:

3

No obligation for long term support, you get what you buy.
You could buy a plugin that would no more have support after some year, no bug fixes and no version for new Blender releases.

I already encountered that issue buying some retopology plugin, the plugin was no more supported at some point , the author selling a new version with more features sold as a new retopoloogy tool.

Hopefully some popular addons have sort of long term support.

This is why i ask sometimes that some features or addons should be included in Blender instead of paid addons.

1 Like
4

To address your questions more specifically-
Yes- the point at which you don’t want to make any more sales. Word travels fast, add-ons that don’t have good support get horrible ratings on every marketplace I’ve seen.

Yep. Technically, when you pay for an add-on, you’re paying for it as it is. Legally, it doesn’t matter if Blender updates and breaks the add-on, you paid for a piece of software and received it. Again, that’s a bad idea as an developer, but there’s no legal punishment for not updating add-ons. I don’t even think marketplaces penalize creators for it

5

There three cases of features, fixing errors, preventing errors, new capabilities.

  • Fixing: these are mandatory because though you didn’t wanted them they were brought up during testing sessions. Users test your software in thousands of different cases.
  • Preventing: This is a technique to secure the code in order to prevent errors. Which is something like excluding use cases in order to prevent “Fixing”. If your addon crashes when a mesh with 1.000.000 vertices is processed, the solution is to prevent 1.000.000 vertices to get into the loop. If you allow it you will allow the “hard constraints” to flood the problem.
  • New Features: The best idea would be to have new features added all of the time do the software, but this philosophy originates from the “Agile” principles that it means that the software is a “service” and not an end product. Is like comparing leasing a car (service) to buying a car (product). Do not expect if you buy the car that the car company will give you service for free (at least after guarantee expires).