What Happens to Open Source Code After Its Developer Dies? (wired.com)
An anonymous reader writes:
The late Jim Weirich "was a seminal member of the western world's Ruby community," according to Ruby developer Justin Searls, who at the age of 30 took over Weirich's tools (which are used by huge sites like Hulu, Kickstarter, and Twitter). Soon Searls made a will and a succession plan for his own open-source projects. Wired calls succession "a growing concern in the open-source software community," noting developers have another option: transferring their copyrights to an open source group (for example, the Apache Foundation).
Most package-management systems have "at least an ad-hoc process for transferring control over a library," according to Wired, but they also note that "that usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it." Evan Phoenix of the Ruby Gems project acknowledges that "We don't have an official policy mostly because it hasn't come up all that often. We do have an adviser council that is used to decide these types of things case by case." Searls suggests GitHub and package managers like Ruby Gems add a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time.
Wired also spoke to Michael Droettboom, who took over the Python library Matplotlib after John Hunter died in 2012. He points out that "Sometimes there are parts of the code that only one person understands," stressing the need for developers to also understand the code they're inheriting.
Most package-management systems have "at least an ad-hoc process for transferring control over a library," according to Wired, but they also note that "that usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it." Evan Phoenix of the Ruby Gems project acknowledges that "We don't have an official policy mostly because it hasn't come up all that often. We do have an adviser council that is used to decide these types of things case by case." Searls suggests GitHub and package managers like Ruby Gems add a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time.
Wired also spoke to Michael Droettboom, who took over the Python library Matplotlib after John Hunter died in 2012. He points out that "Sometimes there are parts of the code that only one person understands," stressing the need for developers to also understand the code they're inheriting.
The guy who has the root password to the internet deletes all repositorys and it ceases to exist.
It becomes public domain
open for anybody to continue? That is exactly the advantage of open source.
The last paragraph of tfs bothers me.
Good code is written in a way which makes it inherently usable, auditable, and understandable by others.
Undocumented, obfuscuated, or otherwise impossible to deal with garbage spaghetti code violates a subtle but important principle of good open source.
I'd say if it cant be forked for reasons of being full of shitty unmaintainable code, let it rot.
Sometimes I wonder if Webalizer (web server log analyzer) has been orphaned in a manner similar to this thread's topic. Last I checked, the website (webalizer.org) is still up, but no one seems to be home.
Zero support. Zero updates. Zero documentation.
Iâ(TM)m curious what the future of APKs host file generator might be if the unspeakable happens. I hope there is a contingency plan in place to continue development of this awesome piece of software. It really has changed my life.
Trump 2020!
bit bucket?
Yes, the code is available, it's open source, after all.
The question the article gets to is how do packagers such as Red Hat or CPAN decide which version to include by default - the old, established one that hasn't been updated, or the new one that has updates but not not the long history? That may be a case-by-case issue by it's very nature.
The other point raised is that programmers, up open source or proprietary, should make sure that two other people have commit access, or will get it.
In my most significant software I wrote by myself, I included a "dead man's switch" which I'm thinking about activating. In the license, I included a clause that said if my web page goes down, non-copyright is automatically passed to a certain person (I maintain my rights as well). If they choose not to maintain the software, two other people are named. If none of those three picks it up, it automatically goes GPL and anyone can do what they want with it, including providing updates and support as part of their business.
The person I passed it along to a few years may not be actively maintaining and supporting it, so I may post it relevant forums declaring that I'm now licensing it open source. I may also contact some of the people that make "competing" software and let them know they can freely use my old software, or parts of it, in compliance with an open-source license I'll select.
I accidentally typed
non-copyright is automatically passed to a certain person (I maintain my rights as well)
That should say:
non-exclusive copyright is automatically passed to a certain person (I maintain my rights as well)
They got full rights to do whatever they wanted with the code, expressed as a non-exclusive license. I also maintained my own rights, so I can theoretically use library routines or any patentable new ideas in my own projects, or allow other people to do so.
I'd have OpenSORES'd it long ago except for what goes on here (trolls harassing & even threatening me/my program etc.) but I've seen what happens in that regard via Google Chrome EFast (a malicious doppleganger created out of its "open source").
* Besides, I've already accounted for it should I "kick the bucket" etc. - it'll go to my nephew who works @ Apple...
(Its doing well enough as is so far! E.g. - Alexa shows it's one of, if not 'THE' most popular page @ Start64 (shows the page for my program is ~3% of the total site's traffic in fact)).
APK
P.S.=> Anyhow/anyways (per the bold above) - He'd most likely continue it IF needed (& I have a version here that is already a GOOD 50% faster on HUGE datasets that I haven't released to the 'general public' as I test the hell out of things a good 1/2 yr. prior to release publicly)... apk
..is that has no gating dependencies on the original developer.
If something is opensource then either it already has other people to keep working on it, or it wasn't filling anyone else's real need anyway, so doesn't matter if it fades away.
See ReiserFS. Its there for anyone to use but the project is dead for all intents and purposes.
See subject: Mine, yours & others seeing your childish bs trolling - You're welcome to do better than I but it's beyond your abilities/skills & maturity level too.
APK
P.S.=> Unbelievable - grow up... apk
The good, well-documented, test-covered and well-behaving code goes to heaven repository. The other codes are incorporated into Microsoft products.
What if an open source developer you know but don't like very much happens to succumb to a dreadful accident? Posting anonymously...for a friend...
As long as you license it under the GPL, someone can fork a new version if you no longer wish to maintain it.
If the code is released under the GPL (or LGPL), then only the owner of the copyrights has the right to "take it closed", for example, to release proprietary extensions that would otherwise require public release of the source code. Of course, the owner can also sell a "commercial license" allowing paying customers to do the same. And many companies have done this, including MySQL AB, Trolltech, and NGINX.
So if the owner of GPL'd software is a single person and s/he passes away, does the right to make proprietary extensions to the code vanish for eternity?
The same thing that happens when a developer loses interest in a project. Either someone steps up to maintain it or it sits in stasis until then. It's certainly a better situation to be in than to be stuck with closed source stuff after the company goes under or stops supporting it.
Someone comes along, looks at it, decides it's all garbage, decides that they can do better, and rewrites it. The only real difference is that those using it in their own product have the option of locally sticking with and maintaining the old code.
And take their useless brittle language to Hell with theirselves.
Someone takes it over and uses it to distribute malware.
Old programmers never die, they get redirected to /dev/null.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
or just goes dark.
Google is supporting PCC a criminaql organization from Brazil to wash money. Some artists from TV are involved becaue they need drugs and child prostitution. They use some small cities like USA used Chile as a political school to test their methods againt police. And I don't have any doubt they would kill developers after public jobs using their names using fake documents.
Yes, the code is available, it's open source, after all. The question the article gets to is how do packagers such as Red Hat or CPAN decide which version to include by default - the old, established one that hasn't been updated, or the new one that has updates but not not the long history? That may be a case-by-case issue by it's very nature. The other point raised is that programmers, up open source or proprietary, should make sure that two other people have commit access, or will get it.
That's neat when you have someone to name as your heir before your untimely demise, but it's not like most projects has an over-abundance of volunteers looking to secure their rank in the line of succession. For most projects I think it would be quite unclear who, if any, is going to step up and take over in advance. Maybe they need to feel the void of your absence, maybe they're secretly hoping someone else will pick up the mantle, maybe they don't want to take on the commitment they'd feel as the named successor. This would be more like a system to enable the project members or trustees to create an interim solution, where you have to hand over control that you wouldn't give on a day-to-day basis.
For that I'd probably go with something like Shamir's Secret Sharing algorithm and a grace period to prevent hostile takeover, like if 5/8 of those I've given a vote claim that I'm no longer leading the project and I'm unresponsive for a week then they get to appoint a new project leader. That way they essentially have no power individually, but collectively they'd have the power to declare me "dead". If the project is so tiny you're the only one in it you could give the votes to people you trust in related projects. What you don't want to do is say "project abandoned, up for grabs" and have random hackers/bots take over, add malware and push it as an update. Hopefully those you hand the reins to have some sense in picking a successor.
Live today, because you never know what tomorrow brings
If it's a useful project, we would likely see a fork of the project similar to:
LibreOffice from OpenOffice
MariaDB and Percona from MySQL
LibreSSL from OpenSSL
Kompozer from NVU
Icinga from Nagios
XOrg from XFree86
The list is much longer, but these are instances of forks that were done in many cases in spite of the original developer.
Assuming that the developer did not explicitly designate succession plans, and that the developer's heirs don't have an interest in the project, the code becomes abandoned property. The law in most countries recognizes abandoned property as available to anyone who wants it, whether that is physical property or virtual. For example, if you take a refrigerator out to the curb for trash pickup, anyone who wants it is free to take it and use it however they want to. If software is abandoned, it would legally fall under the same principle.
I get the issues involved, the desire of many in the open source community to require users of open source software to make their own software also open. Still, I find it ironic that the open source community is worried about what people might do with open source software after the author dies. If it were truly open, one would think that they would be happy that the source code now continues to be free for anyone to use or modify!
My experience is that on projects with few contributors, those contributors care about the project - they are using it in their business or their own larger project, so one will be willing to take over even if only for their own self-interest. I've taken over a few projects for that reason. I became the maintainer not because I'm altruistic, but because I needed the software to work.
It becomes public domain
No it doesn't. When someone dies, unless their wills says otherwise, any copyrights go to their estate. It is up to their heirs what happens after that.
But a certain number of years - defined in legal code - *after* that, it does indeed become public domain. Pedantically you were correct.
I get the issues involved, the desire of many in the open source community to require users of open source software to make their own software also open. Still, I find it ironic that the open source community is worried about what people might do with open source software after the author dies. If it were truly open, one would think that they would be happy that the source code now continues to be free for anyone to use or modify!
kids these days- no respect for lawns.
No it doesn't. When someone dies, unless their wills says otherwise, any copyrights go to their estate. It is up to their heirs what happens after that.
Generally this is true, although there are some other ways they can be transferred (e.g. they may be transferring the copyright via a community property agreement, living trust, buy-sell agreement, marital property agreement, or other instrument upon their death). The important thing is to make sure your estate planning attorney knows that you have contributed to open source projects and knows what you want to happen to your copyrights when they draw up your documents. Part of that should also be leaving good instructions for your executor in terms of how they should reach out to project co-maintainers.
Making plans in advance means someone down the road may have the ability to issue your software under a more permissive license or to enforce the GPL, for example. This applies also if you become disabled--ideally you should have some kind of instruction regarding open source projects with your power of attorney. (If you want help in Seattle or want me to find someone in your neck of the woods who does this, let me know and I can either help out or ask around, as appropriate.)
Real lawyers write in C++
It becomes public domain
No it doesn't. When someone dies, unless their wills says otherwise, any copyrights go to their estate. It is up to their heirs what happens after that.
Irrelevant, its open source so someone forks the code and continues on. What the relatives want is irrelevant, all they have is an old project name. Well that and possibly the right to dual license it. But the existing open source recipient lose nothing even if it gets dual licensed by the new copyright owners.
If a project is useful it will be forked and maintained by a new maintainer. Linux will survive perfectly well without Linus Torvalds. Do the original developers of gcc even still contribute?
If people need new features, they can add them. They will do so because it's easier than finding software that does what we want.
The comment section on this story reads like a "here is why you just use a BSD license" testimonial.
We can hope, can't we?