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.
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.
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.
Its a DIFFERENT problem.
OP is talking about never creating because of fear of maintaining. How many good ideas have never come to anything because of this idea?
So? You as the original developer actively wanted to get away from it, don’t care what happens to it afterwards.
I’ve never not cared about my code. And If I didn’t care about users depending on it I’d feel like a monster.
I love the way of describing Free Software. Paraphrasing and I don’t recall the source: “Not free as in speech or free as in beer. Free as in puppies.” You can get a puppy for free but then you have to take care of it all the time, and it incurs costs like vet visits. Free Software can be the same way.
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
Apache. The problem is there is foundational software in the world that is aging and not being actively maintained. Basically they jump into action when someone catches a security issue, but also that way too many of those security issues only get found when they’re being actively exploited. Even if it’s being used by your bank.
I recall reading about a university ?compsci? lab where the professor who leads it assigns her students to examine priority dependency chains. They trace everything back and report on who is maintaining various upstream packages, and identify situations where it is like just one person or otherwise really vulnerable. Then they have some sort of institutional resources to offer that person support and add extra hands to the workflow. So it is more proactive than what you are describing in that they are going out and looking for things that could be problems, not just awaiting a disastrous exploit and patching it up after the fact.
But it’s just some small group somewhere. On the main I think we agree on the deficit of support for FLOSS components and applications that functionally run the whole world. It’s so crazy but invisible. I am not a developer, just a fan of developers and their work. Most people I know IRL are not developers. Everyone thinks the software on their phone works because Apple and Google pay engineers to build everything. They don’t know about all the FLOSS components to the phone, the services it uses, the network etc, and how so many bits and pieces are maintained in part or in whole by volunteers on their free time.
Remember when the boat got stuck in the panama canal and everyone was suddenly interested in supply chains? I forsee/fear the event that prompts the whole world to learn about dependency chains.
Relevant xkcd
That was the Suez Canal lol
yes axactly
omg i stand corrected
https://en.wikipedia.org/wiki/2021_Suez_Canal_obstruction
also it only lasted 1 week?? i felt like it was 9 months long
TODO: read the wikipedia beyond the introduction