Main Area and Open Discussion > General Software Discussion

Fairware: an interesting experiment in getting paid for Open Source

<< < (3/26) > >>

mouser:
EDIT: Looks like App beat me to posting some details but i'll leave my post unchanged.


Looks like I'm going to spend part of today reading the articles at http://www.hardcoded.net/articles/ -- looks like great reading  :up:

Welcome to the site hsoft!

It sounds like your approach is working, and shares a lot in common with the approach we've followed here.  You can read the 2006 article I wrote about our approach here.

Some similarities I see:

* Assessing the problem: We both agree that users not donating has little to do with not being willing to pay, and more to do with not wanting to go through the hassle of paying; i think laziness is only half the equation -- the other is that they view paying as too high a financial risk compared to the benefits.
* Dealing with people who actively want to circumvent the system: Solution = Don't worry about it, it's not important.
* License Key: We both use a license key for contributors to bypass a nag reminder to donate.
Some differences that are very interesting

Nag screen and non-contributors:

In our programs (that use license key system), we offer a free license key even to people who do not contribute.  They can either download a 60 day key anonymously, or a 6 month key by signing up at the forum.  This has been the source of quite a bit of confusion and hand wringing.  But it's also a way that we maintain that our software is genuinely free for all, and avoid having a nag screen shown on each use.

In your case, you always show a nag screen to non-contributors (as long as their are unpaid hours).  This is quite interesting actually.  Based on my informal experience, i suspect this is a huge part of getting donations.

I think if we did that we would greatly increase the number of donations.  Perhaps by several orders of magnitude.  The reality is that a nag screen on every startup of program is a much stronger incentive to contribute than any please we might make.

However, in our case, with closed source -- the closed source freeware community would very likely decide that this turns the software from freeware into shareware.  I think i would take issue with that and would probably argue that "nagware" shareware is designed to really nag and annoy the user while they use their software (making it largely a requirement to contribute to peacefully use the software) -- it's a hard argument to make.

And i suspect that most of our freeware site friends would disown us.  Your case is somewhat different because at that same time that you are "inflicting" non-contributor users with a nag on startup, you are providing the source code that would theoretically allow them to modify the code and remove it; and because you fall into the open source camp and not the freeware camp, you don't have the same kind of complaints and culture that objects so strenuously to the idea of a nag screen.  Which leads to the open source difference..

Open Source Difference

The most obvious difference is of course the fact that your programs are Open Source while our license-key applications (mostly mine) are closed source.  This is the part that I am very interested in because it's an issue I've struggled with.  I have some open source projects on DonationCoder but they don't really get donations and I don't really push for them on those tools, largely because I've not though it practical or worth the effort.

It's heartening for me to see independent open source projects like yours succeed in getting funding.  I have written before that i lay much of the blame at how hard this is on the open source *culture* which i view as tragically not putting any energy into cultivating a culture of users financially supporting open source projects.  To me it seems that open source funding is another example of a scenario where only a couple giant projects get all the funding, and where 3rd parties are figuring out how to scoop up all the potential available funding for a project, usually by providing pay-for-support of someone else's code.

To me the best future world we could move towards is one where digital content (music, software, art) is all free and generously supported by optional user-chosen donations.  But to do that it requires (in addition to easier and safer donation making) a shift in culture that emphasizes the importance of supporting such creators.  I find it tragic that the open source community didn't/doesn't embrace this as one of the core tenants of open source.

But back to the details that I think are interesting about your experience.. First, you talk about my concern with doing open source donationware-type software, the prospect of someone forking your software and starting a new project without the nag screens or where they put their own nag screen redirecting donations to them.  Basically you have said that it could happen but doesn't -- or hasn't so far -- perhaps primarily because it's too much effort for someone to do.  I think for the most part your analysis is probably correct -- that it's more of a theoretical problem than a practical one.  However, I do wonder whether the likelyhood of such a thing happening starts to go up dramatically as the popularity of a program increases, and as you have more developers.  So i really do still wonder about this fundamental forking problem when thinking about open source software as donationware.

Dealing with software projects where there are many developers:

I find myself drawn to your basic approach -- which is to say that author contributors keep track of their hours and payments get split among the unpaid hours of the developers.  However this is another case where i worry about your approach scaling up when you start to have many developers and perhaps some that disagree about direction. I do note that on your page listing developers that for all intents and purposes it's just you.  It may be a case where i'm worrying more about theoretical problems rather than technical ones, but on the other hand I am interested in finding a theoretically solution that would scale up and be something that could be advocated for large projects and which one could feel safe about it not becoming unmanageable.

More thoughts later..

mouser:
Two suggestions:

* On the contribute page, make a way to let user send a general contribution not tied to a specific product.
* Let users add a comment to the paypal payment (there is a flag for this when setting up paypal details).

hsoft:
Exciting times! After having read your one-year-of-donationware article, it seems like we agree completely on the underlying issues of software development, ethics and money. The only difference seems to be in the approach, and although I place more importance in the source being open than you apparently do, I like the donationware approach too. I wish I had known about this site sooner.

I, too, am unsure of whether the fairware approach scales. I wish other developers participated in the projects I started so I could know whether it scales, but they don't. Why? I'm not sure. There's the language, Python, which is not as widely known as C#/Java/etc., but I'm not sure it's the reason. I wish I knew. Now all I can do is speculate.

So if I had to speculate about the "forking" issue, I'd say that the "danger" is unlikely, even at a bigger scale. I see two possibilities for forking:

1. Out of spite. For some reason, the user really dislike the nag and, out of spite, creates a fork. Well, not only does that person need to spend time building the app for all platforms, but he also has to promote his fork, which unless you spend money in advertisement, can only be done in the long term. Long term means that for every release the original developer makes, you have to merge the improvements and re-build and release. The guy (or gal) would need to have a lot of spite.

2. For profit. The license is BSD (except for PdfMasher because I integrated GPL code, so it's GPL). It's perfectly legal to create a closed source package out of it. However, unless they make significant improvements or spend a lot of money in advertising, I don't see why the users would choose this fork over the original. Moreover, I openly welcome developers and offer them to log their time so they can be paid for it. The only possibility I see is if a developer want to introduce a feature I don't want, or if I don't like the code style, or if for some reason I reject the participation. But then, the fork would have legitimate reasons to exist.

About the two suggestions: I doubt that they'd work with fairware. With this site, I have no doubt that many people make donations to the site "in general", but I think it's unlikely to happen to fairware since it's not a big community like donationcoder is.

All that being said, I'm all fired up and excited because of the many similarities between our approach and I'm pondering about possible cooperations. I've got to think about it some more...

mouser:
I suspect you are right about the low-risk of forking.

There is an interesting psychological phenomena at work when thinking about this stuff -- Some people have a really easy time in dealing rationally with a situation where the practical and likely risk is very different from a high-cost low-probability worst case possibility.  I am usually very good at that and generally give little thought to worst case scenarios.  But I must admit that in terms of forking in open source, for some reason i find myself dwelling on it.  I'm not exactly sure why, but it's the one part of open source that i still struggle with.

I think perhaps part of my struggle with it has to do with your points which i think are exactly right:
and, out of spite, creates a fork. Well, not only does that person need to spend time building the app for all platforms, but he also has to promote his fork, which unless you spend money in advertisement, can only be done in the long term.... unless they make significant improvements or spend a lot of money in advertising, I don't see why the users would choose this fork over the original. "
--- End quote ---

I think this is right -- but it may also help explain why psychologically i worry about forking -- which is that i find promotion/marketing/advertising so painful and uncomfortable and unpleasant, and the mere idea of finding myself in a situation where i have to try to make the case that people should stick with my original version over a fork is enough to make me ill.

And i also get very angry with the possibility of 3rd parties making a large profit off of someone else's hard programming work.. Much like lawsuits, my fear is that the primary thing keeping predatory forkers away is these cases is that there isn't enough profit to make it worth while.  Practically speaking perhaps this means that one shouldn't worry about it.  But it's hard for me to not think about running into one greedy or angry person who could cause real turmoil.

I think my other trepidation with forking has to do with a larger bias in open source.  Stallman and other focus nearly exclusively on maximizing the rights and benefits of the users of the software, and give very little concern to the authors.  When I was at university this seemed completely right to me -- what did i care about raising funding or donations for my code -- i wasn't trying to make a living on it, and there were so many other reasons to want to create useful and popular software.

But if you want to move to a model where programmers can actually receive enough direct contributions to survive (no one is talking about getting rich), i find the lack of concern with author's rights to be troubling.  Practically speaking i think this issue rarely comes up (though there have been a few noteworthy forks that have occurred despite adamant protests from the original coder).  But i still find myself wondering if there isn't some way to adjust the forking-rights commonly present in open source so that it still protects users but gives some protection to authors that want to maintain some control of their software...  And some way of building in protection for authors against people whose intentions are to unethically redirect donations to the original authors..


Anyway, I'm glad you found us here and I hope we can continue the discussion about these issues and see if we can learn more about possible approaches and maybe discover additional ideas that work better for both users and coders.  :up:

40hz:
I still think in the long run that its far more practical to develop a working prototype, find some investors, and then release under a standard commercial license model. To improve chances of reaching critical mass, the product should allow full use of the functionality - but shut itself off (or require reactivation) after a given period of time.* Much like Microsoft did with the beta edition of Windows 7. That allows the end-users to see what you've come up with, help identify bugs, and suggest improvements.

It further allows the developer to:


* get valuable feedback
* accurately determine the level of interest in their product
* build a database of users for future marketing and PR efforts
Note that none of the above requires the use of  "open" anything - be it source code or the licensing model.

Open, as a monetization strategy, only really works for major software projects (Apache, the kernal, etc.) where there's either an ongoing market for corporate customer support - or where enough people are making money off it (e.g. hardware appliances) that the manufacturers view contributing code and money as an act of "enlightened self-interest." (Big corps like Cisco, Microsoft, IBM, Google, et al do that all the time.)

For smaller projects, asking for contributions seldom brings in more than a pittance regardless of the number of actual users.

Maybe I'm overly cynical about these things, but to me crowd-sourcing software development sounds (in most cases) very close to this:



I think a lot of it is born out of the attempt to make some money without actually having to sell somebody something. It's a nice idea. But if the primary motivation is to get away from having to market or do selling, you can forget it.

Yes, there are a few Cinderella stories out there about how something became an epic success without any traditional marketing. But for every one of them there are tens of thousands of other successes that came about through intelligent marketing and sales efforts. Truth is, if you want better odds of success, try copying what has already been proven to work. And only if it fails try something different.

So rather than go through the hassles of coming up with yet another alternate development model (since we have freeware, shareware, adware, open, and commercial models already) why not try going with a standard "closed commercial' license approach and see where it leads?  You might be pleasantly surprised.

It's certainly easier to attract investors doing it that way if nothing else.

Just my 2¢


-------------------------------------------------------
*Note regarding deactivation of beta or trail versions:

I would humbly suggest that if software does deactivate after its authorization expires, the developer still allow the user access to any user entered data stored in the program after the expiration. Some export to a standard file format (tab delimited, CSV etc.) would be nice. Remaining functional in a read-only mode would be even better. That way, the user still has access to their data, but is not allowed to modify existing entries or make new ones. I think that's more than fair because it strikes a good balance between not taking anything away from the user that belongs to them while still protecting the developer's interests.

Navigation

[0] Message Index

[#] Next page

[*] Previous page