Help Source Forge Suck

SourceForge and similar free FreeSoftware portals do our industry an immense service to lubricate the pipeline between thinker and user.

Follow these guidelines to ensure your SourceForge project helps bring their huge and pro bono server farm to its knees:

Administration

Accept SourceForge's bundled adware installer with your software, with the download links surrounded by clickbait and misleading "Download now" banner ads. Dice owns SourceForge now, they only care about the money.
Plant tantalizing but vague references to your project all over the web (how it will cure world hunger, increase programmer productivity by a billion fold), but under no circumstances mention what the project really is or what the software does. Your "About" link should only mention your friends' names, your "Overview" page should only talk about how the idea came to you in a dream, screenshots should show your whole desktop with mail and editor windows but nothing else, and when the curious are motivated enough to read your entire 1000 page manual, it will only explain how to use hundreds of menu options, not why, or what the overall point is. (See also README hints below.)
Don't ArchitecturalSpike your project on your own bench to ensure feasibility. SourceForge has an easy signup feature; just pick a name and write a glowing review of your VaporWare.
Then leave it there for a few years, gumming up searches, with absolutely no code behind it. SourceForge is going to start deleting projects have never released any files and that have been idle for more than six months, so be sure to release some random files and post a new "status unchanged" message every few months.
Projects may appear in the release file system, a Web page, or a CVS drop. Real programmers only use the last item, never the first.
Put a screen shot on the Web page of your awesome output. Then put outlinks that merely lead suckers around for a while (like tech support).
Screw the ArtisticLicense and the GnuGeneralPublicLicense - pick a really weird contract nobody ever heard of.
Don't categorize your project in the Foundry system. If you must, pick misleading categories.
Just because your project is still in the Planning stage does not mean you have to declare that stage - pick Production.
Link into your SourceForge project from dozens of irrelevant Web pages in misleading ways.
Attract as many helpful volunteers as possible, but refuse to give any of them any check-in or administrative privileges. Make sure the ongoing success of the project is completely dependent upon your own interests and available time.
Make your contact address a hotmail account - that you never check.
All cool projects have a cool IRC channel. All cool IRC channels have cool IRC bots. All cool IRC bots are hand coded. Spend all your time hand coding an IRC bot instead of working on the smegging project.

Development

Print out HowToWriteUnmaintainableCode and check off each item.
If you actually upload source, only test it on one platform. Don't use KitwareCmake? or the GNU AutoConf tools. Hard code the paths to library dependencies, in many obscure places. Compile and break at runtime if anything's wrong.
Even if your program is simple, you can still break portability. Everyone has a Windows computer, somewhere, to run your console-only program on!
Don't worry about adding those really hard but critical features to your project - just troll around for volunteers to help clean up.
If you depend on a mega-library like Gnome or KDE, make certain you follow its nightly CVS integrations, so you can depend on the absolute latest bugs.
Contrarily, don't shell into ImageMagick to convert formats. Depend on (but don't include) the least popular and most broken source versions of a few formats, mostly obsolete ones.
Write all code in strict K&R-style C (If it was good enough in the 70's, it should still be good today!), or in some new programming language that seems promising. Hurl insults at anyone who suggests use of a popular programming language.
Pick languages so inappropriate their authors roll over in their sleep/grave. Use PHP for a backwards chaining logic solver, Java to access hardware, C++ ExpressionTemplates (compiled on the fly) to transfer XML schema, or SQL for a canvas.
Standardize on 7-space indentation. In only the first and fourth tabstops.

Testing and QA

Real programmers don't UnitTest.
Never, ever look at the contents of the bug-tracking system.
Whenever someone notifies you of a bug, reply "You have the source: Fix it yourself, dimwit!"
Don't ship a DirtSimpleExample - only heinously complex examples
Test nothing but DirtSimpleExamples. HelloWorld and a FibonacciSequence generator are a sufficient set of tests for any development tool.
Oh, yeah, and distribute a patch tool with a personally lazy commit schedule, so you never lose an opportunity for steganographic infiltration & perversion

Documentation

Make sure that the documentation can be edited and generated only by using your own personal undocumented markup language and a bunch of Perl scripts. And then tell people you don't have time to write or update the documentation yourself, and would appreciate some volunteers to do it for you.
If updating an old system, use the old documentation, especially if it was last updated at least two major revisions ago.
Be thorough. Include any documents that are even tangentially related to your project. For example, if writing a chat client, include a copy of the original IRC protocol RFC and a "Welcome to IRC" file written in 1992.
Of course there's a README file; the trick is making the reader thoroughly regret the attempt. Why say "this file says nothing" at the top when you can tease them all the way to the bottom and make them learn it?
Speak l33t.
Spew DoxyGen into the project homepage, based on trivial begrudging and mildly accurate source comments, with no samples.
In every major section of the documentation, include at least one statement to the effect that Windows sucks.

Deployment

Don't go it alone; attract a cabal of sycophants and camp-followers to help. Deploy flurries of new patches, so that only their workstations contain the exact mix of pluggables required to appear to do anything. They will take care of flaming any newbies with the temerity to ask for bulletproof installation instructions. This strategy can be so successful you can undermine established (and installable) projects that then promise a merger with your wonderland of pluggables!
Require a loaded computer with a working 3D Sound card and a custom-built kernel.
Don't put your 'net addresses anywhere in the source. If the user closes their browser, they should never be able to figure out where this tarball came from.
Arrange files in several tarballs by an arbitrary system, such as first letter. Don't arrange them by priority. Give them generic names, like "pkg.tar.gz" and "src.tar.gz".
Create .zip files and rename them to .tar.gz - then tell people your code only works on Linux
Do not ever practice downloading, installing and running your own scripts. Don't start in a new directory; keep the current one so you won't notice if you missed any files. Copy some other project's INSTALL file in.
Ball your tar in the project's home folder, not from the folder above it. This way when users expand the tarball they don't get a properly named sub-folder, they get a zillion sticky files in the current folder. And remember how careful Unix's tar is about overwriting things.
Never upgrade your compiler and libraries to the average. Always use either very old broke versions, or bleeding-edge new versions. Ensure you use features that prevent compatibility with any other version. Don't allow the standard compilers for any platform - require gcc. Check compiler version numbers in the build scripts, and refuse to even try to compile if the preferred version is not available.
The more dependencies on other rare projects (especially VaporWare), the better.
Your customers will all have 36 gigabytes on their drives waiting for you - use it up!

Page named and populated by PhlIp, who has been helping SourceForge suck for nigh on 4 years now.

[DeleteWhenCooked - pro-SF material moved to HelpSourceForgeSucceed]