How it measures up: SourceForge’s new revenue sharing for developers

Responding to a maturing market for download services, open source stalwart SourceForge has recently announced the beta of a new service called DevShare that not only offers downloads but also shares revenue from advertisers with the project. As the longest-serving download-specific service provider (for delivering finished software — the market for component and developer downloads has actually grown), SourceForge seems to have learned from the criticism of competitors and offers close-to-best-practice terms in its new service.

In the search for monetization strategies, some open source projects are turning to software installers. You encounter these when you download a (typically end-user) technology and discover that instead of just installing the software you were looking for, you’re also prompted to install other, proprietary software — a practice sometimes referred to as “sideloading.”

Notably, complete transparency is a key requirement if trust is to be maintained. Saying what is happening, why it is happening, what will happen if each option is accepted, and how to undo the action if it’s not wanted is crucial. After considering these points, I’ve developed an informal best-practices checklist for assessing monetized downloads. Not everyone will want them at all, but for those who do, a metric may be useful.

Best practices for installers Downloaders at their worst sideload other software without notice or permission. Most people regard this as an act of malware, so any company that’s at all concerned about its reputation at least tells you it’s doing something. Even so, the software being installed may have undesirable side effects, particularly with regard to user privacy, and these are rarely highlighted. Even if it’s implied, it’s unlikely to be accurately portrayed. The install is often “opt-out,” meaning that people in a hurry may not realize they have a choice not to install the software.

A good first step in identifying best-practice behaviors for installers is to look at the extent to which developers have control of the user experience. This comes in three stages: opt-in, compensation, and behavior. When an open source developer decides to use an installer tool to deliver code to end-users, that developer must be able to opt into any sideloading being offered. In many cases today, potential revenue gained through sideloaded code benefits only the installer toolmaker; the developer choosing to use this tool should also be compensated.

When the installer is actually in use, most end-users consider it part of their interaction with the developer of the code they’re actually seeking to download. For this reason, it’s important that the developer should have control over the installer’s behavior and can personalize or craft it into a form compatible with the user experience they’re aiming to create.

A key aspect of downloader development should be ensuring that all software installed is honestly described. Partial or misleading information about the software being installed is clearly dishonest and therefore an inappropriate way to begin a relationship with a user. To avoid being considered malware, all software being installed needs to be indicated to the user; undeclared sideloading is totally unacceptable.

Once users are aware of what’s being offered, they should then have the option to opt in. Leaving them without a choice at all is downright antisocial, but even an opt-out does not go far enough because many nonspecialist users click through without reading, trusting the code developer not to pass on malware. In most cases, an opt-out clause is tantamount to deception and abuse of trust.

Finally, and especially for software that has to be updated regularly or will be part of an install workflow, there should be a download freely available that contains only the software the user is installing and that does not perform any additional actions.

Summing all this up, I suggest seven metrics for identifying best practice in download services:

1. Developer opts in and is compensated
2. Developer is in control of installer behavior
3. User opts in to installs rather than needing to actively opt out
4. All installer behavior is transparent; no surprises or side effects, including global system changes
5. The software is honestly described; any special issues or undesirable behavior are not obfuscated
6. Malware is not permitted and there are no pop-ups, pop-unders, and so on in the sideloaded code
7. An alternative non-installer download is provided

So far, SourceForge’s DevShare seems to score well against this metric. The example project SourceForge directed me to, FileZilla, offers to sideload a Windows application that claims to secure Wi-Fi connections. As you can see from the screenshot, this utility might well ring alarm bells — it’s ad-supported, and it inserts itself in network traffic — but the description provides that information, and the install requires a positive opt-in from the user.

SourceForge representative Roberto Galoppini told me that the company positively vets all software sideloads and checks them for unacceptable behavior, including popups/pop-unders and undeclared tracking. In a competitive market for in-app advertising, SourceForge goes as far as it can in avoiding deceptive offers, according to Galoppini. This can even lead to improvements in the original application being downloaded. SourceForge checks that there’s a mechanism to uninstall both the original application and anything the user opts to sideload.

For projects that want to monetize their downloads along with getting full download statistics, the new SourceForge offering looks promising. It’s a welcome change from the assumption by some download-only hosts that they have an exclusive right to monetize in any way they like, even to the extent of deceiving users. In particular, SourceForge’s claims to prevet the software and to ensure uninstalls are possible are refreshing. I’ll be interested to watch uptake as the offering heads to a full release.

This article, “How it measures up: SourceForge’s new revenue sharing for developers,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.