Giving free SaaS accounts to Open Source projects

Discussions
#1

I’m going to offer free Feature Upvote accounts to valid Open Source projects. Some of you may be interested in why I’m doing this. Perhaps you’ve thought of doing this too.

My reasons are a combination of altruistic and selfish.

  1. We use a lot of Open Source projects. Without them, it would not be feasible to run my SaaS. It feels right to give a little bit back.

  2. Remember when Jira was the new upstart bug tracking software that started to replace Bugzilla on a whole bunch of Open Source projects? The first time I ever saw Jira was through an Open Source project. That exposure made me curious. I was contracting at a big org at the time, and had noticed that everyone hated the awful bug tracking software the org was using. The project manager and I snuck Jira into our project, the team loved it, and it spread like wildfire throughout the entire org.

  3. We have an optional “Powered by Feature Upvote” link at the bottom of each web page on our user’s product boards. The traffic coming through that link is now higher than our Quora referral traffic, and is converting pretty well to trial accounts. So it seems logical to get more active accounts showing our “Powered by…” link.

  4. Our big competitor UserVoice clearly states on their website that they do not offer discounts or free accounts for anyone. It is a chance to look good in comparison to them.

Have you tried something similar? Was it worthwhile? Any unexpected pains or gains?

#2

I’ve not got any experience of offering free accounts to open source projects, but think it’s a great idea given your target customer base. I’ve always appreciated this method of giving back to open source projects, it reflects well on the company, even if I didn’t have an OSS project and was going to buy the service. It’s basically freemium with conditions on the free access based on the type of project.

One thing I’ve always wondered about though is the over-head of validating that a project is truly open source, is that easy to do, preferably automatically? Do you even worry about validating that a project is open source if the feature set they get is slightly different and makes it less attractive to customers that would otherwise need to pay?

#3

I think it’s a good idea, but how do you validate? And if I have a trivial coding problem on GitHub, does that public repo qualify?

Along the same lines, offering students with an .edu email is definitely workable.

#4

If you request FeatureUpvote, that implies that you have at least some audience for your trivial coding problem. So I’d say yes, it qualifies - it helps to spread the word to more people.

#5

I’ve put together a web page laying out some conditions. These include:

  • Your project is in active development for a minimum of 3 months.
  • Your project’s community is active.
  • You release updated builds on a regular basis.

Read all the conditions here.

I’ll take a few minutes to manually validate. That will work in the short term. I don’t think we’ll ever get overwhelmed with requests, but if so, I’ll deal with that problem when it happens. :slight_smile:

#6

What are you trying to achieve with those rules?

Free publicity is free publicity.

Why do you care if you get free publicity from a 1 month old project than from a 4 month old project?

And if I start a project today will you tell me to sod off for the next 4 months before I can use FU? When the project actually becomes popular I’m certainly not coming back because you’ve slighted me 3 months earlier. Rational? Maybe not. Human? Very much so.

I do a lot of open source projects (https://github.com/kjk) and you seem to be fundamentally not understanding that most of it (by ‘it’ I mean my own open source work and open source work in general) is a long tail type of stuff.

Your requirements effectively reject all projects that are not full time jobs for someone.

Regular builds? Active community? Haha.

Not to mention: what is regular? what is build? what is active? community where? Neither of those is clearly defined by you.

I get the instinct of not being taken advantage of but who in their right mind would want to cheat given that verifying open source nature of the project is trivial and if someone gets value from FU for non-open source project claiming it’s open source, you can shut them down and they loose all the value.

All you need to say is “it’s free for open source projects” and let common sense run its course.

1 Like
#7

I’d replace “approved by OSI” with “recognized by”. OS folks are averse to business talk. :slight_smile:

The last two requirements, I assume, are enforced by the account type? Because it is worded as if I need to make a decision to keep it public and keep the link. Don’t make me make this decision - it should be nailed down and not changeable.

The remaining 3 requirements - 3 month, builds and active community - I agree with @kjk, they have little sense to me.

Builds are hard to define, especially for tools that are not built - JS libraries, shell scripts and such.

“Active community” is something very vague. I have an OS project with only a few hundred users who are not very talkative, I only get a couple requests a month. But each of these users represents a large installation with (in some cases) millions of users. It is not active for a normal human eye, and yet I need those folks’ feedback, and they are in positions to use FU in their work, too.

I kinda see why you want 3 months age - to prevent a fake OS project created for a sole purpose to run a FU poll or something like that? - but I do not like it either. You suspect a lot of honest OS developers at the time when they just beginning a new project or fork and when they actually need that feedback from their prospective users most. Not cool. :wink:

#8

I run Reviewable and from the start I’ve given free service to all public GitHub repos. This has been incredibly effective, both for marketing and for getting actionable feedback to improve the product. Also, since part of the deal is that every PR linked to a review gets a branded link to the review (you can only turn this off for private repos), it has helped Reviewable be the top third-party search result for “github code reviews”.

I also strongly agree with the other opinions that you should drastically cut down on your conditions. Don’t be too concerned about people trying to “steal” service; those are the ones you wouldn’t want as customers anyway. Better to build up your brand in the OS community and make it easy for actual businesses to pay you than to try to extract every last cent from borderline projects. (In fact, for Reviewable I made the decision early on to also skip charging for personal private repos even though I get no marketing value out of them, just to keep things simple and because most any business willing to pay for a service will have a GitHub Organization account anyway.)

3 Likes
#9

Thanks for the advice, everyone, to be more relaxed in the conditions for free open source accounts for Feature Upvote. I’ll take it into consideration.

#10

It worked for JIRA b/c Github didn’t exist back then

Today - who would want an external product when they have Github issues?

That, btw, was the reason I decided not to provide free licenses to OSS

#11

This is more related to the thread about programmers paying for tools than this thread, but there’s actually a company that makes a better UI for GitHub issues https://www.zenhub.com/

There’s often an opportunity in a big space to do something better or differently enough.

GitHub does an OK job in their UI but there are opportunities to build better issue management, wiki editing and display, better gist handling, better code review, better code browsing etc.

There are companies making money building better version of GitHub tools and piggy-backing on GitHub popularity to acquire users.

1 Like