While working with Processing now for several years, I noticed that some of the most used libraries do never get an update or are maintained actively. Here just a few examples:
oscp5 (last updated on github 5 years ago - contribution manager version is even older)
I am not listing them to blame the developer, I really appreciate the work they did and totally understand that they maybe move on and are not actively contributing to the community anymore. To be honest, I myself also have libraries that are not actively developed and at a point, a library can be feature finished. But in my opinion this leads to a serious problem for the Processing community:
The libraries may still work, but a lot of people would have improvements, that never find the way back into Processing, because the maintainer is not acting on PR & issues anymore. Even worse, because the library owner holds the “key” to the Contribution Manager, forking a library and releasing it is not even possible.
I myself always tried to contact the library manager himself, some of them answered, some not, some where happy that I added something new, but then did not release it (because it’s too much effort). To be honest, that is a bit frustrating.
That’s why I rather consider rewriting a complete library myself and publish it under a new name, instead of contributing to an already existing but inactive one.
And here I would like to open the discussion:
Have you experienced the same?
Do you think it is a problem that libraries are not maintained?
How should we as a community deal with libraries that are not actively maintained?
Are we going to open the contribution manager for forks?
How do we transfer the maintainer? (Should we?)
Btw.: I opened this thread in the Processing forum and not the Library forum, because it is a more general question on how to deal with maintenance of Processing code.
Do you think it is a problem that libraries are not maintained?
Given the PR request & issues counts in the more popular ones, it seems so… Knowing that your PR will never be merged means you simply won’t bother with something, even if it’s a valuable change.
(even the Processing library itself is sitting on 27 PRs).
Are we going to open the contribution manager for forks?
In cases where author is uncontactable, that seems a reasonable option – a fork that doesn’t change the existing functionality/API (only fixes/extensions) should eventually replace the original.
How do we transfer the maintainer? (Should we?)
Yes. The ideal situation would be the author relinquishes repository ownership and transfers it to the community when they want to move on from it. This transfer could be either to the Processing organisation or to another Github organisation dedicated to Processing community libraries (this would have to be created).
The problem is that the library creator provides a stable URL for Processing to download the library in zip format and install it in your sketch folder.
If a library no longer works and someone else takes over its development they must provide their own stable URL and get the Processing Developers to change the new location. I have done this once with Game Control Plus which effectively is proCONTROLL under the hood but had been abandoned by the creator and was never updated for PS3
Yes, today with Github releases, this should not be a problem. I host all my libraries there, using github’s servers and traffic to distribute the txt and zip file.
@micycle Regarding the PR’s, I totally understand that not all of them can be merged, because sometimes they are not of the quality needed for such a project. But I get your point
The question with “uncontactable” is another one. For example I recently contacted a library owner and he wrote back to me. But after two mails, the contact stopped.
And of course I understand that a library owner does not want to transfer it’s “baby” without proper acknowledgement.
I agree that it is an issue, and not only affecting Processing. Also happens with openFrameworks. But there it is a bit better in one sense: I always look at the forks and choose a newer one. I can clone any fork and install it.
That could be made possible for Processing too, although it would take time as libraries would have to adapt, and as you say, it is already hard to contact authors. I’m not sure how, but maybe the list of libraries could be a list of git repositories, and changing the repository URL was possible?. For that to work maybe the repo should contain the library zip file in a known folder with a predictable name, or the library should have a build script. The end goal would be that it’s possible to keep a library in the list of libraries but it’s URL be changed (if the author agrees).
I guess my point is that Processing could address this issue, but given the lower pace of activity during recent years I wouldn’t hold my breath on it happening.
I’ll end up saying that it is sad that it happens, and I think it’s a very useful discussion to have. What happens to software, frameworks and addons long term? How do we deal with decay? With shifting personal goals? Anything we can do about it? Or just let it happen? When we start a library, could we agree on some kind of manifesto or rules that deal with this probable future? Maybe add to the readme: when I no longer have time or interest in maintaining this library I will _________
Hehe sounds like “The Software Will and Testament”
Maybe something like a “sustainability license” could be created?
