SourceForge eyes a comeback
Years ago, SourceForge.net was the premiere hosting service for open-source and free-software projects. But, after changing hands several times, the site ran seriously afoul of the development community in 2015; its staff was accused of secretly commandeering inactive project accounts and of replacing project downloads with installers side-loaded with adware or even malware. In early 2016, however, the site changed hands yet again, and its new owners have set out to regain the community's trust.
To recap, SourceForge was launched in 1999 by VA Linux Systems, which was initially a hardware vendor. Over the next few years, the company acquired several other free-software related sites, including Freshmeat, Slashdot, and NewsForge (where I worked for several years). For a while, VA operated SourceForge.net for "community" open-source projects and offered a separate "enterprise" edition to corporate clients.
After some rearranging, the enterprise version of the hosting platform became the primary product and the company became SourceForge, Inc. Eventually, various pieces of the business (including the enterprise edition of the hosting software) were sold or spun off in different directions, and all that remained was the SourceForge.net hosting service and Slashdot, which were acquired by the job-search site Dice.com in 2012.
Such corporate shuffling is commonplace but, while SourceForge's popularity as a service had been waning in favor of GitHub, under the Dice.com regime, events took a dark turn. In 2013, the company announced a "revenue sharing" plan called DevShare, through which hosted projects could earn a little cash by allowing SourceForge to package their releases into an installer that would also include third-party, side-loaded apps.
Although the DevShare program was initially touted as something voluntary that would be completely under the individual project's control, in May 2015, the GIMP for Windows project discovered that SourceForge had unilaterally (and, some would say, secretly) replaced its release packages with adware-loaded DevShare installers. To make matters worse, the owner of the GIMP for Windows project account, Jernej Simončič, then discovered that he had been locked out of his account and found that SourceForge employees would not restore his access.
As it turned out, SourceForge had quietly started what it called the "SourceForge Open Source Mirror Directory," a program that seemed to entail site management taking over the accounts of project teams that had migrated their software off of SourceForge onto other hosting services. Needless to say, those project teams did not find the "mirroring" welcome: at best, it confused users about where to look for new releases or where to go for help. At worst, users could find downloads coupled with annoying adware, spyware, or other undesirable add-ons that neither the user nor the developers agreed to.
An uphill battle
Shortly after the 2015 controversy, Dice.com announced that it planned to sell off Slashdot and SourceForge. The sale took place in January 2016 to BIZX, LLC. New president Logan Abbott posted a message announcing plans for the site soon afterward, including:
In May, SourceForge started scanning all downloads for malware. On June 8, Abbott appeared on Reddit to hold an unofficial "Ask Me Anything" session about the site. He highlighted the fact that the new management team was unrelated to the one on hand for the DevShare debacle, promised to continue modernizing the site's functionality, and vowed to further move away from the shady practices of the recent past.
For instance, Abbott noted that SourceForge has been criticized for allowing misleading ads that look like download buttons; staff is now working to remove these ads, he said, and users would soon be able to report them. He also reported that SourceForge has given all seized project accounts back to their original owners, and added:
To be sure, restoring the community's trust in the SourceForge name will require quite a bit of effort. On top of that, rebuilding the hosting service into a competitive challenger to current market leader GitHub will not happen overnight, either. In the first comment linked-to above, Abbott noted that the site still gets over one million unique visitors every day, and hosts more than half a million active projects.
In the discussion, Abbott noted a few changes already in the works, like a site redesign and the addition of servers outside the US.
What might surprise some in the free-software community is that so many participants in the discussion expressed optimism that SourceForge could be resurrected and turned into a modern project-hosting service. Evidently, the site still has its fans. User "FluentInTypo" commented that SourceForge is more convenient to hosting large binaries (including ISO images) for download. When Abbott asked for input, user "pier4r" made several feature requests, such as integrated Gist-like code-sharing and support for holding discussions outside of issue comments. Many others in the thread shared their own feature requests.
Looking forward
To be sure, many of the feature requests offered in the debate are not new; most (like the lack of a general-purpose discussion tool) are common requests whenever users lament gaps in GitHub's feature set, too. But that is telling in and of itself; despite all the conventional wisdom that GitHub is "too big" to catch, complaints about the service's shortcomings are not difficult to find.
It is also interesting to note how many projects still use at least some SourceForge services, even if they also use GitHub, GNOME or KDE servers, or their own infrastructure. To cite one example, FontForge has migrated its code to GitHub, but continues to use its old SourceForge-based mailing lists. Such inertia is a subtle issue keeping projects on their existing infrastructure; while GitHub and other services make it relatively easy to migrate code repositories, migrating bug trackers, mailing lists, and other materials is rarely as smooth.
And, of course, many long-term developers may be reluctant to jump ship to whatever the latest hosting site du jour is. SourceForge's day in the sun may have been a long time ago, but one must not forget that not all that long ago, Google Code had its turn as the go-to hosting destination. When Google Code was launched in 2006, it was seen as vastly superior to SourceForge; it took several years for GitHub to supplant it.
Whatever the cause, there are still many free-software developers
using SourceForge. The new owners have a lot of ground to make up,
but it is far from out of the question that SourceForge could make a
recovery and prove itself relevant again.
Posted Jun 23, 2016 4:54 UTC (Thu)
by josh (subscriber, #17465)
[Link] (12 responses)
If SourceForge wants to come back, they'll need to build something significantly *better* than the current alternatives, not just "as good as".
For example, what if SourceForge built a completely federated solution, where everyone can have their own "home" server hosting their own repositories and clones of other people's repositories, and pull requests work across servers? I'd absolutely use that instead of Github.
Posted Jun 23, 2016 8:12 UTC (Thu)
by wahern (subscriber, #37304)
[Link] (7 responses)
As for pull requests, Git was built to generate email messages with embedded changesets, not to mention from remote repos. When people send pull requests via GitHub, I do the pull and merge from my local repo cloned from my upstream server, push to my upstream server, and separately push to GitHub. (I could automatically push to GitHub with a commit hook on my server, but I don't.) GitHub tracks the merge all the same as-if you used their web interface and merged directly into their repo.
I'll never depend on GitHub precisely because of what happened to SourceForge. Fortunately Git was tailor made to make hosting your own publically accessible repos incredibly easy.
The only thing missing is bug management. There are tools for integrating that with your Git repo, but ultimately you don't want random people to have write access to your repos, so it's not very practical to decentralize that. I use GitHub mostly for the issue tracking, and because other people prefer their web interface to Git's command-line. (That and few geeks run their own server anymore.)
Posted Jun 23, 2016 8:27 UTC (Thu)
by jeff@uclinux.org (guest, #8024)
[Link] (1 responses)
If you run a git (or mercurial) server, just run a Trac instance for your repo or repos. It's very easy to set up, and there are plug ins for just about everything. For personal ones, I just use the SQLite database backend, and everything is in simple files.
Posted Jun 24, 2016 12:19 UTC (Fri)
by bernat (subscriber, #51658)
[Link]
Posted Jun 23, 2016 14:19 UTC (Thu)
by josh (subscriber, #17465)
[Link] (2 responses)
Posted Jun 25, 2016 0:03 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (1 responses)
Whether GitHub has some special tricks not already supported by Git for merging branches with crazy histories, I don't know. But I've never personally had a problem merging pull requests directly into my non-GitHub repos, and every time I've pushed to my GitHub-hosted mirror repos their issue tracking system automatically recognized the association with the pull requested generated on their website.
In terms of slick interfaces, I don't disagree with you that better interfaces can be useful. I was only pointing out that I don't see a need for an additional federation protocol to implement such things; just a way to insert a branch URL hosted on third-parties. In other words, all you need is for both ends not to intentionally implement proprietary interfaces, but merely retain and expose what Git already implements.
For bug management and similar tasks, that would require specifying additional formats or protocols. But the current environment sadly favors walled gardens. (Think the demise of XMPP, rise of Facebook and Slack, and the move to Docker, Snappy, etc, which make it easier to ship tightly-bound software packages that don't need or want or can actively hinder cooperation outside it's sheltered environment.) Outside of certain W3C standards, Git itself (which specifies a de facto protocol, both literally via http:// and git://, and by dint of its layout) might be one of the very last successful "open" architectures we'll see anytime soon. And it's probably not a coincide it's in a context related to open source software, and specifically to a project like Linux.
I think the best bet for federated bug tracking would be some standard for maintaining bugs within a repo based on a specified filesystem layout, synchronized via submodules, subtrees, a parallel repo, or some similar mechanism. It wouldn't be completely federated because core repos would still need to selectively (at least at first) choose which remote repos to pull bug tracking from, but it would be pretty close. Bugs and other "tickets" could be labeled according to the SHA-1 hash, just like any other commit.
And the cool thing is that it could even be done _without_ requiring much server-side software beyond a basic batch program for merging remote issue-tracking branches. Similar to Git's "dumb" HTTP protocol, viewing could be implemented entirely browser-side. In fact, now that I think about it, with Git's "dumb" HTTP protocol you could probably implement an entire bug tracker via a browser application and no additional server-side software anywhere. All it would need is a list of Git URLs to load, and for the repos to follow a specified layout and format for issue items. Creating or modifying a ticket only need involve updating your own repo; integrating comments and replies into an integrated timeline for an issue can happen in the viewer.
Posted Jun 25, 2016 2:38 UTC (Sat)
by josh (subscriber, #17465)
[Link]
A branch URL provides enough information to process a pull request, but not enough information to post one. I'd like an API to programmatically post a pull request, so that I can visit my local instance where I have a clone, see a list of recent branches I haven't already posted pull requests for, click "request pull", and have it show up on the remote instance I cloned from.
Similarly, I'd like to have a federated discovery protocol, so that I can visit a *remote* instance, click a "clone" button, and end up with a clone in my local instance. That could work by way of a web-based protocol handler (https://developer.mozilla.org/en-US/docs/Web-based_protoc...) registered by my local instance.
Posted Jun 23, 2016 14:28 UTC (Thu)
by seyman (subscriber, #1172)
[Link] (1 responses)
One could argue that bug management in Github is so lightweight that it might as well be missing.
Posted Jun 27, 2016 3:54 UTC (Mon)
by gdt (subscriber, #6284)
[Link]
I'd disagree. The bug tracker in GitHub is trivial. But if you're just running a small project it is marvellous: no complex workflow, but better than a set of post-it notes around the monitor. For these minor projects the lightweight GitHub bug tracker is far better than nothing at all.
Posted Jun 27, 2016 0:47 UTC (Mon)
by david.a.wheeler (subscriber, #72896)
[Link] (3 responses)
Posted Jun 30, 2016 11:30 UTC (Thu)
by pboddie (guest, #50784)
[Link]
I also wish them luck. And the SourceForge story has a number of lessons for those infatuated with GitHub, especially those who apparently believe that competition is one horse doing victory laps around the track while they applaud. Allura is now an Apache project. Normally, I would regard that slightly negatively because it usually means that a project's corporate steward has thrown it over the wall in a fit of abandonment, but here it provides another solution as well as resources that could benefit other projects of this nature. Personally, I believe in integrating the best separate tools rather than reimplementing barely-good-enough tools as part of a monolithic forge: Allura's Mercurial history viewer hasn't been as good as hgweb, and I'd rather use something like MoinMoin than the usual Markdown or reStructuredText wiki implementation that forge developers think is good enough. But at least we hopefully get to learn any useful techniques about managing large-scale forges - plus other good stuff - from the Allura code, as opposed to being resigned to delegate the satisfaction of our needs to yet another company while being told that only well-funded, potentially-exploitative corporations can develop and deliver such solutions.
Posted Jul 1, 2016 1:43 UTC (Fri)
by ras (subscriber, #33059)
[Link]
Allura's developer workflow isn't as near slick as github's as it is more focused on hosting then being a development tool. In practice this means they make it easier for the user of your project to download and use it, at the expense of exposing developer tools up front.
As a hosting site for supporting users it makes github look lame. Everything is there: bug trackers, mailing lists, project web site, your choice of VCS, a CDN for binaries and form a users point of view it's fairly well laid out.
That suits me fine - I do development on my laptop, not on a hosting site. In practice, that means apart from the bug tracker the only time I go time I go near Allura is when I do a release. Except, I don't have to go near it even then because they have made everything scriptable (unlike, ahem, Bitbucket). To upload a new release for me it's just "make upload; [test]; make release-tag; hg push". No screen scraping required - just make and the usual linux command like tools. In practice I suspect doing things locally and uploading only when necessary is more productive that doing things through the cloud, which is what github's interface encourages.
And yes it is open source, and it is the obvious and worthy successor to FusionForge. But have you ever tried to install it? It's a nightmare of dependencies. They have fallen into the pip, virtualenv trap in a big way. If it weren't for that I trying to set up an alioth-mark-II based on it.
Posted Jul 2, 2016 20:04 UTC (Sat)
by jengelh (subscriber, #33263)
[Link]
Twice is the charm. The old VA SourceForge had been made available as well - and found its way to e.g. savannah.(non)gnu.org, and other *Forge forks, like apparently gforge/fusionforge.
Posted Jun 23, 2016 7:06 UTC (Thu)
by petur (guest, #73362)
[Link]
Posted Jun 23, 2016 15:59 UTC (Thu)
by rcochran (guest, #105426)
[Link] (2 responses)
Migrating mailing lists to Github is not simply "rarely smooth" but
Posted Jun 25, 2016 0:26 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (1 responses)
I used to host public lists with Mailman, but I stopped long ago. It got to the point where major functionality was missing without running it's web-based GUI component. But I refused to do that because, like random PHP websites, it's a security disaster. (Or, at the very least, I have neither the time nor inclination to keep it from becoming a disaster.) And it's spooling, queuing, and configuration systems are completely opaque and tortured. It too complex for the vast majority of basic needs, yet not complex enough for massive lists required by big commercial vendors.
There are better alternatives to Mailman, but none good enough for me to bother dealing with. The only sane way to run a personal, non-hosted service in the long-term is to pick your software carefully. The nexus of security, functionality, and simplicity is elusive. But I'm convinced[1] it exists for any conceivable problem, though it's certainly not easily found.
[1] I.e. I believe. I.e. I have faith :)
Posted Jun 25, 2016 17:45 UTC (Sat)
by lsl (subscriber, #86508)
[Link]
Which ones? I recently looked into mailing list software and what I found was sobering. I would *love* to have missed (or misjudged) something.
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge eyes a comeback
[...]
> In terms of slick interfaces, I don't disagree with you that better interfaces can be useful. I was only pointing out that I don't see a need for an additional federation protocol to implement such things; just a way to insert a branch URL hosted on third-parties. In other words, all you need is for both ends not to intentionally implement proprietary interfaces, but merely retain and expose what Git already implements.
SourceForge eyes a comeback
SourceForge eyes a comeback
SourceForge developed and runs Apache Allura
SourceForge developed and runs Apache Allura
SourceForge developed and runs Apache Allura
SourceForge developed and runs Apache Allura
SourceForge eyes a comeback
SourceForge eyes a comeback
> code repositories, migrating bug trackers, mailing lists, and other
> materials is rarely as smooth.
rather impossible. Github doesn't offer mailing lists at all. That
is the only thing that keeps my project on SF.
SourceForge eyes a comeback
SourceForge eyes a comeback