No, you just see this in the stage of a classic maintainer pass. I mean, look at pyjulia itself:
It had one maintainer pass before. Now before someone says it’s some weird Julia thing, look around. Here’s libuv.
It’s now passed to its fourth hands, some weird Jameson Nash dude. That’s a core cross-platform asynchronous I/O thing that all languages rely on… seems scary to have print possibly not maintained in any modern language? Somehow no one got mad or scared during its maintainer lull, I wonder why.
Alright, but what about open source anyone here would know? Here’s OpenBLAS:
It’s passed three hands before, and most people never really noticed and instead called it stable.
I can keep going, but this happens all of the time. It’s nothing to be scared about, it happens all of the time with dependencies that everyone uses, and when I mean everyone I mean things like the SSL encryption used for the whole web and stuff have gone through similar stages. Most open source projects have 1 or 2 people really active on them at a given time, and they tend to pass hands when the first maintainer goes on to do other things. It happens across all languages, domains, and beyond. You can find a lot of nice papers about this that started researching it back in the Heartbleed era of open source.
But okay, we’re greedy programmers, what can we do about it?
Well, if there’s someone willing to pick up a given project, we could look for some infrastructure grant to support them. Finding funds isn’t too hard, there’s NSF CSSI, NASA ROSES, etc. we could write for one of these calls. I write these for the community and it’s a lot of time to keep putting out an average of a grant every two weeks, so if anyone else could pitch in that would be great. Writing some Python bridge into some grant is relatively easy and can probably just ride as pork into some other SciML thing.
But even after getting the funds, someone would still have to step up to do this work. That was Taka before 
. After Taka, I’m not sure who else is willing and has the knowhow to do this. If anyone knows anyone who wants to do it though, put them in touch with me and we can figure something out.
Probably the best thing to do is to get in contact with the PythonCall guy and see what his career stage and goals are. He’s of course interested in the topic, but what is he doing and where is he going? What could help him out the most? Did anyone even ask? That’s the first thing to do. While it is always a PITA to have to change some fundamentals like this, maybe he’d be willing to help diffeqpy and PySR swap to PythonCall, and maybe he would like to do it full time if only there was support. That’s a very concrete step.
Maintenance-only mode never really happens on purpose. It’s only identified years after the fact that a hobby you’d like to try is something you never picked up. It’s that next book on your shelf that you intend to read, and have intended to read for the last 5 years. It’s probably a good time to now call it in maintenance mode and someone in this thread should probably make a PR to the README asserting that, but it’s not like there was any intention for someone to disappear without putting it onto the README. When exactly it happened is a blurred line, and only clear that it has happened after the fact. I wouldn’t try to place blame on someone for something like that.
You’re way over generalizing here, like, to a crazy extent. If there’s something that have always fallen apart in every language I’ve ever used, it’s language bridges. Why are language bridges in particular so hard to keep open source maintainers for? Well I finally found out first hand when doing some of the MATLAB.jl maintenance. The problem is that language bridges are generally started and maintained by someone who’s working on projects between two languages, so they need it themselves. But what we’ve seen with the Julia language bridges is that, over time those maintainers end up with essentially 100% of their projects in Julia and so many of them tend to become core maintainers of the Julia language itself (since they already know some system programming stuff from building language bridges, it’s a natural transition).
So arguably it was easier in 2017 or so to find people building lots of new language bridges in Julia. That’s the peak of MATLAB.jl, mexjulia, juliacall (R), etc. PyJulia had its revival at around this same time, where there were enough libraries that people really started adopting Julia, but not enough to really be standalone. Nowadays, you can just do an entire project in Julia pretty comfortably, and many students are learning it as their only language, so the pool of people who are naturally building and maintaining such bridges shrinks. These days, a lot of the people with write access to MATLAB.jl probably don’t even have a MATLAB license anymore, I know I don’t .
Given that it is such a natural process though, it does make a good argument for a targeted correction to accelerate its development.
. The package seems like such an extremely good return-on-investment that it’s painful, as a Julia user hopeful for wider Julia adoption, to watch the repo collect dust. If I was in charge of some grants to open-source communities, this feels like the highest impact project to support.
