| |||||||||||||
SourceforgeSourceforgePosted Jan 24, 2008 10:51 UTC (Thu) by johnny (guest, #10110)Parent article: Ten-year timeline part 3: The Tucows years
Slightly OT, but what is it that makes Sourceforge a "last resort"? I'm not asking because I feel a need to defend SF or anything, it's just that I want to know what I'm missing out on when I'm using SF (SF is the only site if its kind that I've used) instead of an alternative. In short, what are the alternatives, and in what ways can I expect them to work better for me than SF does?
(Log in to post comments)
Sourceforge Posted Jan 24, 2008 12:21 UTC (Thu) by epa (subscriber, #39769) [Link] The alternatives I most know of are Savannah (a Sourceforge clone run by the GNU project; your app must run on a free OS) and Google Code (pleasingly minimalist interface, but you must have a gmail login to participate). There are others.
Sourceforge Posted Jan 24, 2008 14:14 UTC (Thu) by net_bh (guest, #28735) [Link] There is Launchpad by Canonical.
Sourceforge Posted Jan 24, 2008 16:42 UTC (Thu) by tzafrir (subscriber, #11501) [Link] There's also http://berlios.de/ . Use a gforge as well. Had both and subversion and a wiki long before sourceforge had it. Generally less reliable than soruceforge.
Sourceforge alternatives Posted Jan 24, 2008 15:16 UTC (Thu) by TRS-80 (subscriber, #1804) [Link] Website and source hosting and bug tracking are commodity items these days - most of the major projects (e.g. GNOME, KDE, Samba) self-host. Sourceforge only got SVN a few years ago, while DVCS eliminates much of the need for an always-on central source repository. I've always had a special hate for SF's bug tracker, even Bugzilla is better, and its mailing list archives are horrible as well, despite being run on Mailman. Smaller projects can often find a hosting provider tailored to their needs - mozdev, freedesktop, RubyForge, Alioth, or even run their own trac install on a $10/mo shared host. The wikipedia comparison of free software hosting facilities only compares supported VCS, but gives an idea of the breadth of options available. It's been a long time since SF was the only source hosting game in town, but its features haven't kept up at all.
Sourceforge Posted Jan 24, 2008 15:16 UTC (Thu) by roblatham (subscriber, #1579) [Link] Some of sourceforge's problems relate to just how many projects they host. For a while in 2003-2005, for example, the CVS servers were just not reliable. They've addressed that. For a lot of projects, it's not a big deal to register a domain and host your own mailing lists and defect trackers. Maybe that process was more difficult back when bugzilla was all we had, but now we've got RT, TRAC, and a bunch of others. We've got SVN but also a ton of distributed revision control tools. Plus, as other comments have said, there's more than sf.net today. ==rob
Sourceforge Posted Jan 28, 2008 10:32 UTC (Mon) by KotH (subscriber, #4660) [Link] Back in the days, SF was unreliable. I don't know the exact reason but i suspect that they acquired more projects in a short time frame than their servers could cope with. The result was that their cvs server was more down than up and mails took at times over a day to be delivered over the mailinglists. The cvs issues were mitigated a bit by introducing a commit only cvs server for developers and a second read only one for all the users. Although this made development more reliable for the developers, the problems remained for the users and they got the additional problem that commits would take a day to be visible to them. As a result of these problems, first MPlayer and not much later FFmpeg moved to their own server. At that time it was interesting to see, that after FFmpeg moved their cvs repo to the MPlayer server, SF's cvs server became quite a lot faster. It might be coincidence, but still funny to see. I don't know whether SF still has these problems, i haven't used it for a very long time. But i guess that they got enough hardware and a proper scalable framework to cope with it these days.
Sourceforge Posted Jan 29, 2008 0:14 UTC (Tue) by jd (guest, #26381) [Link] Reliability issues - it had an amazing amount of downtime at one point. Sourcecode secrecy - the source was supposed to be released, but barring one early snapshot, it never was. The loss of the build farm came later, IIRC, but that made life far harder. Mirrors were often out of sync, so you had to hunt-and-peck to see where the updates were. Everyone could see uploaded files (they still can), which means any project can "steal" files from any other project until completely set up. Mailing lists are partially outside Sourceforge, so Sourceforge users can have a hell of a time resetting passwords. The mailserver on Sourceforge was unreliable, so mail sent to your Sourceforge account routinely vanished into nowhere. Oh, and the space available made quite a few projects tough at best.
|
|||||||||||||