Archive | Open Source Business RSS for this section

DevShare Relaunch: Power to end-users!

Back in July 2013 SourceForge launched the beta version of the DevShare program, a partnership offered to SourceForge developers to turn project downloads into a source of recurring monthly revenue by presenting relevant offers for user consideration during the installation process.

Today, we are proud to announce that DevShare is open to everyone. After spending nearly a  year listening to developers and end users about what they wanted to see in a public release of this offering, we’re ready to give our community an overview to the changes we’ve made to DevShare.

Direct Download Links

Filezilla Project Page - Download optionsProjects that are participating in the DevShare program will now provide two options for download. They will offer:

1) The installer Enabled version which presents optional third-party offers at installation time.

2) A Direct Download link to the original application that does not include offers.

Filezilla File Page - Download options
By giving end users a choice  we will strengthen our ability to help open source projects earn revenue, in order to continue developing, while giving end users the freedom to control their user experience. These options are offered at every stage of the download process, so whether you are downloading from the project page or from the file page end users will always have the choice.

Clear Messaging to End-users

The download page now clearly states when projects include an additional offer. Clear Messaging messaging alerts you that downloading the custom installer may present you with additional offers.

We have also created a FAQ page to ensure that everyone understands how the program works and has the option to learn more.

By giving power to end-users and making the DevShare program parameters clear, we believe we have significantly improved the DevShare program. SourceForge users, developers and the whole open source community have been key to the changes in this program. Thank you for your feedback and for being a partner in growing this community.

Opening the Program to Everyone

In re-launching the program we are going to open it to all our open source developers who wish to monetize their downloads. As always only projects who opt-in will get into the program. Every project owner has the choice to participate in DevShare or to not participate.

If you want to know more about the program read the Developers FAQ, and feel free to drop us an email at

Usability in Open Source Software – Guest Blog post

From our friend Jim Hall of the FreeDos project…

Open source software developers have created an array of amazing programs that provide a great working environment with rich functionality. At work and at home, I routinely run Fedora Linux on my desktop, using Firefox and LibreOffice for most of my daily tasks. I’m sure you do, too. But as great as open source can be, we’re all aware of a few programs that just seem hard to use. Maybe it’s confusing, or has awkward menus, or has a steep learning curve. These are hallmarks of poor usability.

But what do we mean when we talk about usability? Usability is just a measure of how well people can use a piece of software. You may think that usability is an academic concept, not something that most open source software developers need to worry about, but I think that’s wrong. We all have a sense for usability – we can recognize when a program has poor usability, although we don’t often recognize when a program has good usability.

So how can you find good usability? When a problem has good usability, it just works. It is really easy to use. Things are obvious or seem intuitive.

But getting there, making sure your program has good usability, may take a little work. But not much. All it requires is taking a step back to do a quick usability test.

A usability test doesn’t require a lot of time. In fact, usability consultant Jakob Nielsen says that as few as 5 usability testers are enough to find the usability problems for a program. Here’s how to do it:

1. Figure out who are the target users for your program.

You probably already know this. Are you writing a program for general users with average computer knowledge? Or are you writing a specialized tool that will be used by experts? Take an honest look. For example, one open source software project I work on is the FreeDOSProject, and we figured out long ago that it wasn’t just DOS experts who wanted to use FreeDOS. We actually determined there were three different types of users: people who want to use FreeDOS to play DOS games, people who need to use FreeDOS to run work applications, and developers who need FreeDOS to create embedded systems.

2. Identify the typical tasks for your users.

What will these people use your program for? How will your users try to use your program? Come up with a list of typical activities that people would actually do. Don’t try to think of the steps they will use in the program, just the types of activities. For example, if you were working on a web browser, you’d want to list things like: visiting a website, bookmarking a website, or printing a web page.

3. Use these tasks to build a usability test scenario.

Write up each task in plain language that everyone can understand, with each task on its own page. Put a typical scenario behind the tasks, so that each step seems natural. You don’t have to build on each step – each task can be separate with its own scenario. But here’s the tricky part: be careful not to use terminology from your program in the scenario. Also avoid abbreviations, even if they seem common to you – they might not be common to someone else. For example, if you were writing a scenario for a simple text editor, and the editor has a “Font” menu, try to write your scenario without using the word “Font.” For example, instead of this: “To see the text more clearly, you decide to change the font size. Increase the font size to 14pt.” write your scenario like this: “To see the text more clearly, you decide to make the text bigger. Increase the size of the text to 14 point.”

Once you have your scenarios, it’s just a matter of sitting down with a few people to run through a usability test. Many developers find the usability test to be extremely valuable – there’s nothing quite like watching someone else try to use your program. You may know where to find all the options and functionality in your program, but will an average user with typical knowledge be able to?

A usability test is simply a matter of asking someone to do each of the scenarios that you wrote. The purpose of a usability test is not to determine if the program is working correctly, but to see how well real people can use the program. In this way, a usability test is not judging the user; it’s an evaluation of the program. So start your usability test by explaining that to each of your testers. The usability test isn’t about them; it’s about the program. It’s okay if they get frustrated during the test. If they hit a scenario that they just can’t figure out, give them some time to work it through, then move on to the next scenario.

Your job as the person running the usability test is actually the hardest of all. You are there to observe, not to make comments. There’s nothing tougher than watching a user struggle through your program, but that’s really the point of the usability test. Resist the temptation to to point out “It’s right there! That option there!”

Once all your usability testers have had their chance with the program, you’ll have lots of information to go on. You’ll be surprised how much you’ll learn just by watching people using the program.

But what if you don’t have time to do a usability test? Or maybe you aren’t able to get people together. What’s the shortcut?

While it’s best to do your own usability test, I find there are a few general guidelines for good usability, without having to do a usability test:

In general, I see Familiarity as a theme. When I did a usability test of several programs under the GNOME desktop, testers indicated that the programs seemed to operate more or less like their counterparts in Windows or Mac. For example, Gedit wasn’t too different from Windows Notepad, or even Word. Firefox is like other browsers. Nautilus is very similar to Windows Explorer. To some extent, these testers had been trained under Windows or Mac, so having functionality – and paths to that functionality – that was approximately equivalent to the Windows experience was an important part of their success.

Also, Consistency was a recurring theme in the feedback. For example, right-click menus worked in all programs, and the programs looked and acted the same.

Menus were also helpful. While some said that icons (such as in the toolbar) were helpful to them during the test, most testers did not actually use the quick-access toolbar in Gedit – except to use the Save button. Instead, they used the program’s drop-down menus: File, Edit, View, Tools, etc. In fact, testers experienced problems when the menus did not present possible actions clearly.

And finally, Obviousness. When an action produced an obvious result, or clearly indicated success – such as saving a file, creating a folder, opening a new tab, etc. – the testers were able to quickly move through the scenarios. When an action did not produce obvious feedback, the testers became confused. These problems were especially evident when trying to create a bookmark or shortcut in the Nautilus file manager, but the program did not provide feedback, and did not indicate whether or not the bookmark had been created.

Usability is important in all software – but especially open source software. People shouldn’t have to figure out how to use a program, aside from specialized tools. Typical users with average knowledge should be able to operate most programs. If a program is too hard to use, the problem is more likely with the program than with the user. Run your own usability test, and apply the four themes for good usability, and make your open source project even better!

Jim Hall is a long-time open source software developer, best known for his work on the FreeDOS Project, including many of the utilities and libraries. Jim also wrote GNU Robots, and has previously contributed to other open source software programs including CuteMouse, GTKPod, Atomic Tanks, GNU Emacs, and Freemacs. At work, Jim is Director of Information Technology at the University of Minnesota Morris. Jim is also working on his M.S. in Scientific & Technical Communication (Spring 2014); his thesis is “Usability in Open Source Software.”

Want to Pitch a Silicon Valley VC? It’s Your Time to Shine!

Tim Draper by JD LasicaIf you are a startupper and a fan of the role of open source in startup development, it is your time to get a feedback on your pitch from noted Silicon Valley venture capitalist Tim Draper. Thanks to the editors at Dice News, Draper will sit down with three startup founders on Jan. 23, 2014, at his Draper University in San Mateo.

SourceForge developers are invited to take a chance to try out their latest and greatest idea.

Here’s how it works:

  • Email your business plan, a brief founder’s bio and a paragraph on what level of funding you’re seeking.
  • Make your subject line “VC Pitch.”
  • The Dice News editors will develop a short list of entrepreneurs and send them to Draper. He’ll make the final selection of who’ll pitch to him.
  • The closing date for submissions is Jan. 10, 2014.
  • Those who’ll pitch will be notified on Jan. 17.

We’ll be recording each presentation for stories to be posted on Dice News. Once your pitch is done, we’ll interview both you and Draper to find out what went well, and where you need improvement. While no one’s promising any funding, everyone will come away with valuable tips on how to improve your pitch when soliciting angels and VCs. If you’re looking for some inspiration about how to shape your business model, make sure to read Brent C. William’s slides.

Some fine print: If selected, you’re responsible for your own transportation to Draper University.

Best of luck!

SourceForge BlockThis Initiative Update

Last week, we launched an initiative aimed at removing misleading ads that display a download button without disclosing the name of the product and we want to update you on how this program is progressing.

A task force of people working in the AdOps, Community and Product departments reviews daily the notices sent in from the community, in addition to the work we do on our own.  We process requests by following these steps:

1. Reviewing the advertisement to confirm they are misleading;
2. Identifying the advertising network partner/s displaying those ads;
3. Removing those ads; and
4. Proactively reviewing all additional partner networks to find similar ads.

In a week, we received a handful of community notifications and we found 90% of them legitimate. Thank you!  We took action accordingly, eventually communicating back our findings and actions.  This has resulted in SourceForge blocking +20% of misleading ads, with more work ongoing.

This is just the beginning and we are fully commitment to improving our site and removing misleading ads.  We continue to ask for your patience and assistance, as this is a continuous process.  If you see what you think is a confusing ad, please send a screenshot of the ad itself and the URL of the site where the ad leads. Send to:

Advertising, Bundling, Community and Criticism

Over the last days, we heard a number of concerns around how our business practices affect the community sentiment. A few concerns were expressed by several developers, included the GIMP community, about confusing ads on SourceForge pages. Along with that, we also heard complaints about the DevShare program. We want you to be assured that we are always listening to you, learning from you, and taking action on your feedback.

1. About the Confusing Ads

We work with several different Ad Network partners like Google to show ads on our site, and from time to time, a few confusing ads show up. Just like all of you, we do not like these ads, and last month, we asked our Ad Network partners to remove over 200 deceptive ads; however, it’s an ongoing process and we need your help.

In order to eliminate these sometimes misleading ads from SourceForge pages, we’re asking you to drop us an email at providing the screenshot and, more importantly, the full link to the confusing ads [to copy it right click on the link, and choose “Copy Link Location” in FireFox; “Copy Shortcut” in Internet Explorer; “Copy Link” in Safari and “Copy Link Address” in Chrome]. We will make sure to review all such requests, and if we agree with you, take immediate action. Please help us to make SourceForge a better place. Your input is material to help mitigate this issue.

2. About Bundling Open Source with Additional Offers

In July 2013, we launched a pilot version of an opt-in revenue-sharing program called DevShare. DevShare is a partnership program offered to SourceForge developers to turn downloads into a source of revenue for them, by bundling their applications with third parties’ offers. This revenue will help these projects grow, help the developers keep contributing to the Open Source community, and help us keep offering free hosting, distribution, and other services.

Let’s start by providing some context around this issue first.

We started the DevShare program for two reasons:

  1. Some projects were already using the SourceForge infrastructure to deliver bundled offers to monetize their downloads, and most of them were complaining about the lack of control on the quality of the offers and user experience. In addition, many other open source projects expressed interest in monetizing their downloads by bundling relevant offers, but the lack of control with Installer Partners was a key concern for them.
  2. SourceForge also makes a small amount of revenue from this program to continue offer free hosting, distribution, support and ultimately to keep enhancing Allura, it’s fully open source platform now in incubation at Apache.

Therefore, we evaluated a few Installer Partners to help us address end-users’ complaints related to one or more of the following reasons:

a) opaque installation flows providing little or no choice about secondary offering installations;

b) undocumented and difficult to uninstall procedures for those secondary offerings;

c) secondary offerings that are not always safe, trusted and secure applications.

We addressed points a) to c), and our approach was highly appreciated by eminent members of different open source communities.

What DevShare Means to You

End-users are provided with a clear and transparent installer behavior, all programs are malware-free and clearly described. All uninstall procedures are extensively tested, so that if end-users install it by mistake they can easily remove it.

Developers aren’t just compensated in money, but they are in full control of both the installer behavior and what sort of secondary offerings will be presented to their users.

Where are We and Where are We Going

Currently in the Pilot phase, we only have 3 projects participating in the DevShare program all of which explicitly opted-in. This represents 3 out of 300,000+ projects in our entire catalog. This is a 100% opt-in program for the developer, and we want to reassure you that we will NEVER bundle offers with any project without the developers consent.

The DevShare program has been designed to be fully transparent. The installation flow has no deceptive steps, all offers are fully disclosed, and the clear option to completely decline the offer is always available. All uninstallation procedures are exhaustively documented, and all third party offers go through a comprehensive compliance process to make sure they are virus and malware free.

Having said that, we believe we should do more to make sure all our stakeholders are pleased with the program and how it works.

In the near future, we’ll share a blueprint of how we believe this program can be improved, and we’ll ask the community for feedback. We will not be accepting any new projects into this pilot until the community has vetted possible changes and improvements to the program.

In Closing

You are welcome to join the conversation at the DevShare forum on SourceForge, your opinion rules.