6 ms·
This is the best way to conclude a project like this, I wish more clear cut "this is the end" choices were made. An ecosystem with zombie projects isn't healthy
by oneplane 3y ago
This is the best way to conclude a project like this, I wish more clear cut "this is the end" choices were made. An ecosystem with zombie projects isn't healthy.
- stavros 3y agoWhy? I wish people would put their projects in something like https://www.codeshelter.co https://www.codeshelter.co so anyone who's interested can maintain them, instead of just killing them.
- bornfreddy 3y agoDo you, as the project maintainer and possibly even founder, trust these people?
- stavros 3y agoThe maintainers are vetted before joining, and are removed if they do something untoward, but when the choice is between killing the project or giving it to some random person, Code Shelter provides a better alternative.
- sthlmb 3y agoWhat if they pass the joining process but then later sneak something in that goes undetected until things go boom? There are alternatives, you can fork the original project, and things will go on. As others have said too, you can just update the underlying software and there's a good chance that the wrapper itself will continue functioning, providing there are no giant breaking changes and by that point, a fork or alternative will likely have handled it.
- stavros 3y agoWhat if there's no joining process, and they contact a maintainer directly, and peer pressure them to hand over the project, and the maintainer does, and then they sneak a backdoor in some binary test files?
- eropple 3y agoThat scenario is exactly what PiVPN is avoiding by refusing to nominate a new maintainer and telling interested parties to fork--so what is your actual and concrete objection? Fork the project. Earn your own trust.
- stavros 3y ago> so what is your actual and concrete objection? This: > I wish people would put their projects in something like https://www.codeshelter.co https://www.codeshelter.co so anyone who's interested can maintain them, instead of just killing them
- eropple 3y agoSo to me that says you want it both ways, for while I appreciate what the codeshelter folks are trying to do, it is a task that is going to turn out Sudden But Inevitable Betrayals. Instead of contacting a maintainer directly, they just look sufficiently polished that codeshelter says "yeah, sure, OK" and hands it over. Forking the project and earning your own trust really is the safe path forward.
- Narishma 3y agoThey can still fork the project and continue maintaining it if they want. Nobody's stopping them.
- reachableceo 3y agoThe project can be forked with a single click. That’s the beauty of GitHub.
- BossingAround 3y agoYou can maintain it right now. Make a fork, and continue development. You might even get some shoutout from the original devs. It's all open source after all, making this repo read-only doesn't mean the project's dead if the community is vibrant enough.
- stavros 3y agoThe community matters. It's one thing to get control of the official websites, official packages, etc, and another to have to tell every single user "come use my fork".
- planb 3y agoBut this is dangerous. There are many „Jia Tans“ out there who would love to continue maintenance of those projects with the full community.
- stavros 3y agoYeah, we always knew there were. Open source can't stop existing because there are bad actors.
- sevg 3y agoSo you're saying that if projects continue choosing to sunset without handing over the keys to the kingdom, open source will stop existing? This is simply not even close to true. Edit: I can't reply to your reply, so here will do. You've completely ignored my main point. I get that you want projects to pass on the torch, but saying open source will otherwise die is ridiculous.
- stavros 3y ago"Continue choosing to sunset"? A large amount of projects does not sunset, it gets passed on instead.
- 3y ago
- 8n4vidtmkvmk 3y agoIsn't xz a prime example of why we don't just hand over the reigns anymore? Like the guy said, they can just fork it.
- prmoustache 3y agoIt is not killed, anyone can pull the repo and work on it.
- logicziller 3y agoHe did mention in his post that he's not gonna handover the project to someone he doesn't trust.
- MuffinFlavored 3y ago> I've been giving less and less attention to PiVPN, and the desire to keep up with it is no longer what it once was. I wonder if financial/monetary incentive would change this. I don't think it would personally (because putting a value on your free time/mental load/time you can spend with your loved ones doing something else away from the PC is precious) On the flip side... $500/mo? $1k/mo? $5k/mo? I'm sure most projects that go "defunct" open-source-free-no-financial-incentive-thanklessly-help-build-something could probably find "motivated maintainers" for $3k/mo on average? Internationally? Is the "capitalist" answer "this repo and all of its efforts are not worth $3k/mo to the open market"?
- DeathArrow 3y agoWho will pay? For sure there are developers willing to take care of it if they are payed, but who is willing to pay them?
- powersnail 3y agoA lot of these projects are made in people's leisure time, without profitability, for other fellow geeks, and the users also uses them in their hobbies. And as fellow geeks, we are more likely to be financially poised to be on the other side of the equation: getting paid to write code, rather than being able to pay a developer's wage, at least not in the long term, not in any maintainable manner. Can you afford to pay yourself 3k/month to maintain such a project, without any profitability, just for a hobby?
- ianlevesque 3y agoAgreed. Also often the gap between what people will pay for a hobby project and what money is being made at a tech company by the people who have the hobby is vast. Sometimes there are contractual restrictions on taking money from other jobs simultaneously that complicate it.
- Nullabillity 3y agoYou could probably get someone, but would you get someone good (competent, trustworthy, etc)? Perhaps Jia Tan is looking for a new gig.