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

SourceForge is offering to share download revenue with open source developers. Here's how the plan stacks up

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.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform