Date: Sat, 16 Feb 2008 11:06:09 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Danny Pansters" <danny@ricin.com>, <freebsd-questions@freebsd.org> Subject: RE: To sourceforge or not to sourceforge Message-ID: <BMEDLGAENEKCJFGODFOCEEGCCFAA.tedm@toybox.placo.com> In-Reply-To: <200802150223.37679.danny@ricin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Danny Pansters > Sent: Thursday, February 14, 2008 5:24 PM > To: freebsd-questions@freebsd.org > Subject: To sourceforge or not to sourceforge > > > Hi folks, > > II would like to sollicit opinions and advice on whether or not to put a > project on sourceforge or perhaps somewhere else (better?) > > I have put kbtv1 on sourceforge as well as on my own website. Apart from > getting to use sf.net as the first download location in its port I can't > really say that it has been useful in any way. And updating it is a pain. > > Now that I'm starting to distribute kbtv2 (beta) I find myself wondering > whether I should continue to use sf.net or just use my own site > (and possibly > some secondary location in one of our committers' webspaces under > freebsd.org > (easy to add to port). > > My primary objective with hosting my source (and to a lesser extend docs) > elsewhere is availability (and to a lesser extend offloading data > traffic). > You know, just the simple thought "what if I drop dead tomorrow". > > Are there better/simpler/faster alternatives to SF that people recommend? > > One thing I noticed with SF is that there's all sorts of "me-too" > (that is > marketing) websites that just scrape SF and then forever have > outdated info > and downloads. I don't find this desirable at all. And besides, if you're > using FreeBSD you're going to use ports not some external stale > copy of the > source. BUT it appears that there *are* people downloading old > crud from such > sites. > > I tend to have the feeling that simply hosting it my damn self > will work 99% > of the time and cause fewest headaches, but I'm open to any suggestions. > Hi Dan, Let me relate my own esperiences with http://www.freebsd-corp-net-guide.com When I wrote the book I mentioned in the forward I'd have a website setup for updates. I did set the site up, and had a pretty nice site for several years that got some use. But as time passed I updated the site less and less. Then the server the site was on crashed and lost some OS files. I got it back up and tarred up the site, fully intending to host it on different hardware. Well I hate to say it the site is still sitting in a tar file, despite that I have the hardware sitting here running BSD, doing nothing else, really. I agree that sf has attracted a really undesirable element, every bad thing you listed about it is true, plus it has gotten so big now that searching it for a particular project is terrible - Google is a better way to find projects on sf than sf's own search tools are. But, there is still one thing that sf does which can't be matched by hosting it yourself, and that is, to act as a historical archive. I have at least 6 different OSS projects that I've used on a semi-regular basis that were privately hosted at one time that are gone now, except for my personal archives. For example, take FreeIPdb. Sure, ipplan does the same thing and it is still available. But FreeIPdb had some advances in it that ipplan did not have. Furthermore, more importantly freeipdb's code (GPL) could serve as an excellent template for writing a similar program for some other developer. Sure, the "drop dead" factor is of a concern. But I think the liklihood is you personally will get tired of doing kbtv2 before the end of your own life. Hell, even George Lucas got tired of doing Star Wars, that's why we won't see any more Star Wars movies from him. But, other people aren't tired of it. The liklihood is that when you personally get tired or too old or whatever to stay interested in kbtv2, there will still be people interested in it. That is where sf becomes important. sf is one of these things that is more important to the community than to the developers who use it. Unless the project is really large and has a lot of participation, sf doesen't really offer the project developer much. But, a user picking up code from sf knows that even if the developer gets tired of it and loses interest, the code will still be there. One of the biggest loopholes in the various OSS licenses is that none of them guarentee the developer cannot extend control over the project. OSS licenses fundamentally assure the user that if the developer decides later he doesen't want the code out there, he cannot exercise control via copyright to snuff out the project and make it unavailable. But, the fundamental flaw all of them make is that if the project is a niche project, then if the developer decides to withdraw it, there's a good chance nobody will step up to the plate and fork the project. If that happens then a few years later you won't find the source for the project anywhere on the Internet, and there will be one more OSS project lost to the community. And if 10 years later someone comes along who needs a software package that did exactly what niche thing that this OSS package did, they won't have it. If the code is on sf, this sort of thing won't happen. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCEEGCCFAA.tedm>