Artemis was a promising mobile app for Kbin, with a dedicated community, a rapid pace of development, and a high level of polish. Then, the developer disappeared.
This is why I never build any of my app ideas. I don’t want people to notice when I wake up one day and decide I don’t want to work on it anymore. Of course people tend to not like my UX ideas so its probably a fear I don’t need to have.
I thought this was one of the points of open source.
“Yeah, I’m done with this. I’m not making any more changes from what it is today. If you find value in continuing it, here’s the code. Go wild!”
Yes, but if you’re lucky maybe 1 in 100,000 users will be both capable and willing to take up the reins. More often than not, when single (principal) developer projects lose its single developer the project just goes into code rot. ASF maintains tons of projects that are too valuable to lose completely but which have no one doing active development on them. It’s a problem.
Yes, but if you’re lucky maybe 1 in 100,000 users will be both capable and willing to take up the reins
So? You as the original developer actively wanted to get away from it, don’t care what happens to it afterwards.
This. Nothing is more difficult than understanding someone’s else code and architecture, and even if you manage that, you’re now stucked with the choices somebody else made and nobody wants that (we want to make our terrible choices!).
More than a final app, the best thing to publish as FOSS is libraries extracted from it to help other developers build there own products faster. That’s something other may want to maintain when we abandon it. And on top of that, it still help to publish your app using this lib to serve as practical example about how to use your it, of course.
Not sure what ASF is (something Software Foundation?) but sounds like they are a solution and not a problem
I can think of only one concrete example where the lead dev walked away - rightfully IIRC - and the community was able to pick it up, fork it, and actually maintain and continue to develop new features.
Sadly, that’s not often the case.
I think youtube-dl had a situation like that, now yt-dlp. (except I don’t know if the original dev’s status is confirmed?)
also exa, now forked to eza. My impression is for this case, the original dev is OK.
But honestly I have encountered lots of software packages which have been dropped and picked up in this way. Man pages can contain history like this, occasionally going back to the 80s or even 70s for the basics. The main problem is that the original software package is so well known and sometimes it’s hard to find out about the newer iterations so they have a difficult time picking up steam. I used to have a bookmarklet that would show forks on github sorted by activity; occasionally this allowed finding the more recently-developed project. But more likely you have to wait to stumble on it in a forum.
That’s why I open-source everything I work on, or at least, everything I have permission to. I have one or two projects where I have friends who have contributed a good amount of code but don’t want it public so I respect their wishes and keep it private. Everything else I work on though, it’s open-source.
If I can’t or won’t continue working on something, maybe someone else can find it useful and continue working on it.
In an ironic twist of fate, Artemis was stopped in its tracks because the source code hasn’t been released
Oh no, nobody could have seen this coming… 🙄 And people kept downvoting me when I scoff at a release of closed source Lemmy/Mastodon/… clients.
For all intents and purposes, the dev did state their intentions on releasing the code “when it’s ready”, and was super active in working on it. Not releasing, and relying on one server running a specific upstream branch were definitely mistakes, 100%. But, I think the dev legitimately believed they would hit that target, which was a prerequisite for releasing.
I never understood the “when it’s ready” excuse. It’s only not ready when it contains stolen code, otherwise as unstable as the application may be, the code is ready for release.
Kbin didn’t haven’t an API so they were using screen scrapers. I assumed they were waiting for a proper API rollout. But who knows now.
Right? Like, my app is definitely not ready yet its source code is available for all to see. And since I’m currently inactive, you could even fork it and get a bigger following than me if you wanted to.
These people just think too highly of themselves.
This also highlights how important it is that we develop open source apps for the fediverse. Life is hard, busy, and surprising. An open source license works for the good of all of us by allowing development to continue in the face of hardship.
That’s a bit concerning. Leave alone the bad practices of multiple single points of failure (single server, single developer, singler person with access to code), the abrupt silence from the developer Harriette looks very concerning. Hopefully we hear back from her soon enough.
Developing alternative frontends like Artemis at this stage of Kbin development is really putting the cart before the horse. Compared to Lemmy, kbin is much more different than reddit due to is micro blogging capabilities and other Mastodon-like feature, such as boosts, that it is difficult to straight up port a reddit app to Kbin. Development wise, Lemmy is also much more mature, as the backend was already separated from the frontend and Jerboa exist as a reference app, where as far as I can tell, Kbin didn’t have a reference app, or even a backend API at the time.
I’m not a programmer, but it seems to me, in retrospect, that the wise thing for Hariette to do is to join the Kbin dev team, contribute to the main repo, and make Artemis the reference Kbin app instead striking out on her own on a custom implementation and running her own instance at the same time. It’s sad that she appears to be burnt out right now.
