Slashdot Mirror
Ask Slashdot: Aging and Orphan Open Source Projects?
osage writes: Several colleagues and I have worked on an open source project for over 20 years under a corporate aegis. Though nothing like Apache, we have a sizable user community and the software is considered one of the de facto standards for what it does. The problem is that we have never been able to attract new, younger programmers, and members of the original set have been forced to find jobs elsewhere or are close to retirement. The corporation has no interest in supporting the software. Thus, in the near future, the project will lose its web site host and be devoid of its developers and maintainers. Our initial attempts to find someone to adopt the software haven't worked. We are looking for suggestions as to what course to pursue. We can't be the only open source project in this position.
It also makes sense to raise the issue with downstreams such as Debian, OpenSuse, or Fedora (assuming they exist for the project). Or if it is in one of the enterprise GNU/Linux distributions, approach those vendors.
Yeah, if it is open source, why be so protective?
No you should not give just anyone commit privileges or blindly accept patches from unknown
sources...but why all the secrecy?
Where/when is the new site? If nothing else, put up a tarball and maybe someone can run with it.
If you / your company is "out" even a tarball is better than nothing. There are many "free" web hosts
available, with various features.
This is 2014, not 1993.
While I can see not wanting to be slashdotted, there is no magic or secret.
Even code under maintenance with a certain size userbase should perhaps have:
-- regular releases (if nothing else, various OS need regular packages, even if the code has not changed; this
may be more appropriate to let people affiliated with the various OS handle
some projects only release source because they do not want the hassle of "supporting" binaries;
some projects release binaries and only support theirs (not any changes
distros/packagers might make) so if you want "support" you are advised to use the project's binaries
may or may not apply as much if this is written in a "scripting" language, but there are similar issues,
and generally oh-so-many packaging systems to choose from, different run-times/VMs for the same language,
etc.
-- unit tests, a nice web interface with colorful tables
-- bug tracker, place to report security issues
-- mailing list, chat room, screenshots
-- coding standards
-- list of goals/future directions, even if it is a pipe dream and will never happen, it is nice to know
what is possible / what the long-time users/devs wish it could do; ports you would like to see happen
-- docs for devs -- example usage (e.g. API, a library might have sample programs); is nice to have a web version of docs
-- docs for users -- user guide, FAQ, example usage; again, nice to have a web version, if it is kept up to date at least
-- shiny graphs/benchmarks/etc. (depending on nature of this thing) -- how is this code faster/better than other code?
or is that not relevant, the API is so nice, or the code is so clean, or it runs everywhere, or...why is this project
better than any others? or even why is it worse and what needs improved...
etc.
These things may not be "feasible" or realistic if there are few people interested, but without even a place
to grab the code, no website, noone to contact, no mailing list, no chat room, the odds are 0%.
There is no secret. Just do what you do. If you are done, put up a list of "future directions" to hopefully steer someone
where you want the project to go.
I am more worried there is no roadmap than anything else. Maybe everything works and is stable, everything
is feature-complete, no serious bugs.
Where would you like to see this go?
Poor analogy time: It sounds like you /your company are "done" but shopping around for a good "owner",
otherwise your custom-made car will be scrapped.
If you can't sell it, leave it on a street corner with "for free" and a number where you can be reached for the title.
Right now, you have a sign "free car!" but no address to pick it up from, noone knows the make or model or year
or how much $ you put into it, how many miles, or even the color, or whether it runs or not, or what continent it is on.
It sounds more like you want a specific "caretaker" and not just anyone, but haven't outlined what you want from that person.
While this can be a good thing, depending on license it might be mostly futile: either the code is available or not, end of
story. Right now it "is not" [1]
[1] from slashdot POV...there may be many people with the code and a working website, but we don't have any evidence
of that.
I'd rather write a replacement product then help old software limp along. Also old code tends to be ..........
Mature, debugged, and well documented?
Apache has a number of vital, rapidly improving projects. The one that I'm using currently is Apache Spark. We use Solr and Nutch, and they are being actively developed. We're excited about Calcite getting to the point that it is fully featured and stable, and that's progressing.
there are plenty of projects that have moved to the Attic, which is where they go for the long, slow retirement and death. And many of the projects are, I would say, lethargic and not frequently updated, because they are large, stable, and feature complete, but likely to be replaced by other projects. Maven is a good example, where I think there is something better, but there is a large, installed userbase that Apache supports.
Based on his (vague) project description, it sounds like apache might be perfect for it.
The more people I meet, the better I like my dog.