In the late 90s, I was part of a project, which later became a non-profit called Tux.org, who was trying to be an umbrella organization to help Linux related FLOSS projects. We weren't quite at the model of a fiscal sponsor, but Tux had mirrors of projects and the goal of helping others.
Then Sourceforge came out and I remember as a 20 year old trying to talk with them about where they saw themselves in the community, and they were basically dismissive of the work that we were doing.
Nonetheless, they had (at the time) flashy software that made them attractive and many projects used them. They were genuinely the Github of their day.
The ultimate lesson of Sourceforge is three fold for me:
1. Never trust a commercial entity that you aren't paying to be your single repository
This applies to Sourceforge and Github, ultimately.
2. Never use proprietary software as your core
Sourceforge, like Github, was proprietary and used that to keep people in. Like Github, the interface to the internals were FLOSS (Subversion in SF's case, git in Github's case).
2. We need better verification/validation methods to handle malware
Then Sourceforge came out and I remember as a 20 year old trying to talk with them about where they saw themselves in the community, and they were basically dismissive of the work that we were doing.
Nonetheless, they had (at the time) flashy software that made them attractive and many projects used them. They were genuinely the Github of their day.
The ultimate lesson of Sourceforge is three fold for me:
1. Never trust a commercial entity that you aren't paying to be your single repository
This applies to Sourceforge and Github, ultimately.
2. Never use proprietary software as your core
Sourceforge, like Github, was proprietary and used that to keep people in. Like Github, the interface to the internals were FLOSS (Subversion in SF's case, git in Github's case).
2. We need better verification/validation methods to handle malware
We need verified builds