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.

27 of 155 comments (clear)

  1. Options... by Lisias · · Score: 5, Insightful

    "Fork" the thing on SourceForge or similar service. SYNC the repos and web pages there over the time while trying to gather collaboration.

    Perhaps you can manage to get there what your company doesn't. At very least, this will guarantee the project's surviving when your company shuts the support down.

    At very worst, you'll have a way to save the project's source code and documentation to posteriority when the company support ends.

    In the mean time, you can negotiate a hand over to Apache, GNU or any other Open/Free Software Foundation.

    --
    Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
    1. Re:Options... by Anonymous Coward · · Score: 5, Informative

      "Fork" the thing on SourceForge or similar service.

      Also a Dice holding. Bitbucket or github are in better shape these days.

    2. Re:Options... by stephanruby · · Score: 4, Funny

      Also a Dice holding. Bitbucket or github are in better shape these days.

      Wow! You guys are fast!!

      I never expected someone to guess the right name of the project with only the two clues I've given.

    3. Re:Options... by gbjbaanb · · Score: 3, Insightful

      and CodePlex, which although hosted my Microsoft does a better UI job of the overall thing than Google Code (which has dropped support for binary releases, telling you to use dropbox or something instead), and has a pretty poor tracker.

      I found github to be a bit 'meh' too in terms of usability, though still better than google code.

      I'm not sure what the best one to use is, based on functionality and usability rather than something that has 'git' in the name or some vague "startup coolness". If anyone can enlighten us, I'd appreciate it.

    4. Re:Options... by Anonymous Coward · · Score: 3, Informative

      I'm not sure what the best one to use is, based on functionality and usability rather than something that has 'git' in the name or some vague "startup coolness". If anyone can enlighten us, I'd appreciate it.

      I've found Bitbucket to be exceptionally nice, with free public and private repositories, online editing, wiki, etc., but as a lowly user I cannot vouch for its long-term stability.

  2. "Donate" to a Foundation by qpqp · · Score: 3

    Depending on the type of software, you could try getting it into Apache, OW2, or others. Also fork it to github.

    1. Re:"Donate" to a Foundation by Beezlebub33 · · Score: 3, Interesting
      Um...I beg to differ.

      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.
  3. More specific by StripedCow · · Score: 5, Insightful

    Could you be a little more specific about the kind of software this is about?
    That might reveal why people shy away from the project.

    Anyway, in general, keep in mind that maintaining software is boring and does not earn one brownie points.
    Motivating people to write the software from scratch might work better.
    In that case, make sure your functional specs are up to date.

    --
    If Pandora's box is destined to be opened, *I* want to be the one to open it.
    1. Re:More specific by Anonymous Coward · · Score: 3, Insightful

      +1

      Actually naming the project here would help draw attention to it

    2. Re:More specific by Anonymous Coward · · Score: 3, Interesting

      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.

    3. Re:More specific by eclectro · · Score: 4, Informative

      Could you be a little more specific about the kind of software this is about?
      That might reveal why people shy away from the project.

      Tangentially, you manage to bring up a very good point. One huge problem is the software projects might be using. A number of companies open sourced their software before the notion of a 'standardized' license method became prevalent. If a project is not Mozilla, GPL, or BSD compatible then it will have a very hard time attracting new developers. I know would not want to work on something that did not have a useful open source license. I would encourage the submitter to make sure whatever he is working on have a standard, permissive as possible license (if possible) before he closes shop.

      I know one interesting project (from a historical perspective) that suffers from this is the Open Watcom compiler with its non-compatible Sybase Public License. This project fits the submitter's description to a tee. I bet there are others like this. At least POV-Ray got around to fixing their license finally.

      --
      Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
    4. Re:More specific by butalearner · · Score: 5, Insightful

      A bit of Google-fu reveals that osage, the name of the submitter, is also the name a layout/rendering tool associated with GraphViz. It's likely old enough to fit the "over 20 years" comment and was the de facto standard until a bunch of javascript graph visualization libraries popped up and made it easier to create prettier, interactive graphs. The latter explains why younger developers might shy away from it: it's written in C instead of javascript. And it was started by AT&T Labs Research to fulfill the corporate aegis bit. And there is a banner on the Graphviz homepage trying to attract developers.

      So unless this is all coincidence, we may have a winner, which would be sad since I use it on occasion.

    5. Re:More specific by osage · · Score: 4, Informative

      The software is fairly general-purpose, being used in software engineering, bioinformatics, network engineering and social networks, to name a few areas. I should also have noted that we're not just considering maintenance. The underlying field has a lot of work going on it. There are plenty of opportunities to develop new algorithms and provide new features.

  4. commit to GitHub by Anonymous Coward · · Score: 5, Funny

    On GitHub, you don't even need developers. The cloud does everything, through the magical miracles of unicorn sweat and pixie dandruff.

    1. Re:commit to GitHub by Anonymous Coward · · Score: 3, Insightful

      This is the only actual solution. You dump it on github and plaster the link all over your community pages. If the software is actually important, someone will pick it up and continue maintaining it. If not, it was meant to die, but it's corpse is still there in case someone needs to study it someday.

  5. Ask the project community by gmuslera · · Score: 3, Insightful

    If you won't support it elsewhere, ask the community if anyone of them want to host/support it. It just requires an i.e. github account to host the code, and the key pieces of information of forums/wiki pages/etc could be move there by the community if there is enough interest.

    In the end, if the project wasnt developed exclusively by your company developers, it belongs to the community too.

    1. Re:Ask the project community by Florian+Weimer · · Score: 4, Interesting

      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.

  6. Re:Why the cloak and dagger? by PhilHibbs · · Score: 5, Insightful

    Because it can cause embarrassment to the company to admit that their software is in peril. Maybe this guy doesn't have the authority to make announcements to the public on behalf of his employer.

  7. Let it die with you by RR · · Score: 3, Informative

    Yours wouldn't be the first software that has become abandonware. Users may appreciate the stability of an unchanging release. If it's distributed under a Libre license, then it can be forked and redistributed, but chances are that kids would rather make their own mistakes than work on your program.

    --
    Have a nice time.
  8. Re:Why the cloak and dagger? by msobkow · · Score: 3, Insightful

    Not much of an "open" source project if you can't even name it, is it?

    --
    I do not fail; I succeed at finding out what does not work.
  9. A discussion for the ages - literally by eclectro · · Score: 5, Insightful

    This was asked back on Slashdot 14 years ago in 2000. As you can see, most of the websites mentioned that archived "ummaintained" software have since evaporated and are unmaintained themselves!

    Then it was talked about briefly on stackoverflow in 2009.

    Submitter, what I suggest you do is include a text file that describes the history of the project (If it was me - I think it would be nice to thank those by name who made significant contributions), known issues, ideas for direction of the project (if any), and then post it to Github and Sourceforge as an 'ummaintained' software. With as permissive as a license as you can give it, which will encourage it's use down the road. Also, I would post links, notices, and intentions to any associated forums. And give the community as much time to as possible before closing the website down. Maybe someone or some company will have the where with all to continue the project. If it is reasonable to do so and they seem to be reputable and serious, you might let them. Otherwise, when finished, make sure that archive.org has browsed the website for their archives. Also, post a copy the final software there. If it has a domain name, if you can, I'd give it a ten year renewal date and give it a notice of closure and a link to the project on Github.

    But the larger issue for me, is that you, your colleagues, and friends spent time and effort on this project. That should be recognized. At least by acknowledging that support is ceasing for this project, it can hopefully move on to other hands in the future. It does happen.

    I wish more more programmers were as thoughtful as you. And I wish there were better ways (i.e. more permanent and standardized) of dealing with orphanware.

    --
    Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
  10. It's called marketing. by Qbertino · · Score: 3, Informative

    Said this already a while back on a simular problem:
    It's called marketing.

    In short:
    If your project is (re)presented properly, you'll have people falling over each other to claim gouvernance over it.
    I'd put it into a foundation - after refurbishing it's outward representation!

    Example: Typo3's architecture looks like it's designed by monkees on crack, it's config language TypoScript is so bizar - in concept and in implementaion - I can't even describe it and there are a countless other strange things about this software. Yet it has a professional website, ressonable documentation and a solid brand, brandbook included(!). I doubt the Typo3 Foundation has problems finding heralds for it's project. There even are Oreilly's on it.

    Hope I could help. And good luck finding a heir for your project.

    --
    We suffer more in our imagination than in reality. - Seneca
  11. Re:Depends on the project by CaptSlaq · · Score: 4, Interesting

    I'd rather write a replacement product then help old software limp along. Also old code tends to be ..........

    Mature, debugged, and well documented?

  12. Re:Depends on the project by geminidomino · · Score: 3, Insightful

    I don't think I've EVER seen old code that's well documented. Not even stuff from my own larval "Document all the things!" phase... I think subversion feeds on comments.

    Well, on comments and release engineers' tears, when it comes time to merge...

  13. Retired developers by loonycyborg · · Score: 4, Funny

    or are close to retirement.

    Wouldn't a retired person have a lot of time on their hands to contribute to the project? Or it's customary in your country for all people at retirement age to perform ritual suicide?

    1. Re:Retired developers by osage · · Score: 3, Informative

      Actually, I intend to continue to work on it after retiring, but at some time illness, death or some such personal this is going to get involved. It would be nice to have new people involved before then. Also, when the last of us has left the company, it will be difficult to convince the company to continue hosting the web site.

  14. Re:Why the cloak and dagger? by osage · · Score: 4, Informative

    The software came out of the Research organization which at the time had a wide mandate. As there was no interest within the company of capitalizing on it, we were able to get it released as open source (currently, with the Eclipse license). As the software provided a platform for our research, work on it was encouraged. Of late, the company has greatly curtailed research, firing many and convincing many others to leave voluntarily, and restricting work to a few areas. We have moved the code base to GitHub but have kept the web site on its current machine until we decide what to do. As with most companies, managers can be touchy about employees airing concerns publicly.