Going Open SourceVirgil Dupras
Free Software and proprietary software are seldom seen as compatible. Free Software proponents are telling us that users should have the "freedom to run, copy, distribute, study, change and improve the software", and proprietary software developers are arguing that it's very hard to earn money from producing Free Software. Both sides have good arguments, but a consensus can never seem to be reached.
Recently, the author of E Text Editor [dead link], Alexander Stigsen, has made a very bold move [dead link] by opening the source of his proprietary software. Although I'm not convinced by the Trust Metric system he proposes, I think it is a very interesting move, a move that could potentially, finally, reconcile shareware and open source.
Update 2015-01-02: I noticed that, unfortunately, E Text Editor's website became unavailable. That removes a lot of context from this article now, sorry about that.
What The Customer Is Entitled To
While the proprietary software model allows shareware developers like me to earn money from their work, it's important to realize that the customer is being screwed in the process. The customer who commits money and time to proprietary software takes the risk of getting stuck with an unsupported and buggy software. This can happen with both big software developers and small software developers.
With big software shops, it's usually greed that drives customer screwage. For example, Intuit (Quicken developers) seems to want to take the lead in the race for being the dirtiest customer screwer ever. What often happens is that these developers force the customer into an upgrade cycle. Or sometimes, it's that they won't fix a bug until it's "cost effective" (until some manager looking at his maximization chart decides it's worth it). While this is probably all sound behavior, profit-wise, the end result is still that customers are the ones suffering from all this.
But there's the small developer to the rescue! We sure are a fine bunch. A vast majority of us actually care about our customers. So even if we're releasing our software as proprietary, it doesn't really affect the customer because he gets adequate support from the developer.
However, despite the best intentions from those small developers, there's always the risk that they get bought by a large company. When that happens, the large company will of course want to "leverage" (screw) their newly acquired customer base for better profits. Who will suffer? The customer.
For very small companies (one man shows), an additional risk is the risk of the developer getting hit by a bus. If that happens, the source code of the application can either be unrecoverable, or unmaintainable. For someone who never worked on a codebase before, it can be very, very hard for them to figure it out without help from the original author (private code is often poorly documented). When it is, there's a good chance that the code will fade into oblivion, leaving the customers in the dust.
Moreover, as a developer who's also a customer of some proprietary applications, I'd sure like to have access to the code of the applications I bought. If not for fixing minor annoyances or helping the developer with a bug that affects me, I'd also like to know if the application I'm running has a future. Too often, applications look all neat and cute, but it turns out that the code is an unmaintainable mess. Unless you don't want to improve the application, an unmaintainable codebase is worthless.
We can say whatever we want about Free Software, there's no denying that it delivers something very valuable, something that the proprietary software world has a hard time delivering, something I'd like to deliver to my customers.
Earning Money With Free Software
If you ever read or heard an apology for Free Software, you know that it's very important to make the distinction between "free as in beer" and "free as in speech". We are constantly being told that Free Software is not about working for free. We're told that it's perfectly OK -- and possible! -- to make money from Free Software. Here's the examples we're commonly given:
Custom development. Someone has a problem to solve, then you customize an already existing codebase to that person's need. This is actually the most obvious way to earn money with Free Software. Were I in the custom software business, I would most certainly produce Free Software all the time, as it's what makes the most sense in that situation.
Dual licensing. Release your software as GPL, but at the same time, distribute a proprietary version of the same software and charge for the latter. This is also a great way to earn money with Free Software (Trolltech was rather successful with Qt before they got bought by Nokia), but it only works with libraries. For software made for an end user, dual licensing doesn't make any sense.
Donations. Create a good Free Software, be popular, and collect donations. The first problem with this solution is that it doesn't seem to work. I am pretty much certain that, had I released my applications under Free Software to then rely on a "Donate" button, I would have earned a tiny fraction of what I earned by releasing them as proprietary. The consequence of that is that I would have had to find a day job that was not Hardcoded Software, keeping its development as a hobby and thus decreasing the quality of those applications.
One other problem with donations is that Free Software typically have a lot of contributors. Who exactly do you donate that money to? Just the head guy? What about the "unsung hero" who wrote that obscure driver that allows your mouse to work? Does he get anything?
Collect some fame and get a nice job at Google. I guess it's a good reason to contribute to Free Software, although I personally find it a little sick to parade in front of big corporations, begging "choose me! choose me!" with credentials of past unpaid work in your hands. Of course, if you happen to have had lots of fun while doing that Free Software project that landed you that nice job, then you can just ignore my contempt and laugh all the way to the bank (but you don't laugh anymore because that bank had your money placed in CDOs... oops!).
Charge for support. This is actually the way of earning money with Free Software that I dislike the most. In proprietary software businesses, the better your software is, the less it needs support and the more profit you make because you don't have to provide that support. With a business based on supporting Free Software, the more confusing and buggy the software is, the more support it needs and the more money it makes. Making money from keeping the quality of a software low is a bad thing.
Free As In Beer
While it's obvious that in certain areas, producing Free Software is a good way to earn money, in some other areas, like with generic software (software that is not custom software or a library), "free as in speech" usually implies "free as in beer".
I am very lucky to be in a situation where I work on projects that I chose to work on (using languages and technologies that I chose as well!) while getting a comfortable income from it. Unfortunately, I haven't managed to find a way to do so while producing Free Software. The Free Software model just doesn't seem to fit with the shareware model. If I have a good idea for a software application that I think a lot of people would use, what should I do, convince thousands of people to invest 10$ in me so that I develop this application as GPL? Yeah, right, maybe in Wonderland. What happens in real life is that you have to risk months (if not years) of development time, and then convince people to give you money for what you created. If the application is released as GPL, it's impossible to get that money (except maybe crumbles of bread from a "Donate" button).
Because of that difficulty to earn money from producing generic Free Software, there is generally a gap in quality between shareware and Free Software. This is because developers who aren't paid will usually develop those Free applications because it's fun for them. However, some aspects of software development are less fun than others, like improving user friendliness. Hobbyists tend to neglect that kind of work, whereas developers who sell their applications tend to focus on that kind of work.
Narrowing The Gap
What if users of those generic Free Software applications pooled together to pay themselves some developers to work on the boring but necessary parts? That would be great, wouldn't it? Unfortunately, it's unlikely to happen. First, there's the chicken-and-egg problem. If your application is not user friendly, only those who can cope with it will use it, the others will buy a proprietary application. Second, there's the trust problem. Even if some users were willing to pool their money together, they need to find a developer that they trust enough to give him money upfront. It's not impossible, of course, but it's not something that's easy to coordinate. Besides, why pay now for something you'll maybe get later, when you get instant gratification from the proprietary world?
We cannot expect generic software users to pay upfront. I think it cannot work. This is where a move like Alexander's is interesting. He published his application's source under a modified BSD license that says that the licensing code cannot be tampered with. It means that although the source is public, its users still have to pay to use the application. This way, the author gets paid and his customers have access to the source code, as well as the instant gratification from the proprietary world.
Thus, the chicken-and-egg problem is resolved because the developer expects that the people who are interested in using his application will pay him. Therefore, it makes sense for him to risk some of his development time and to make sure that his application is user friendly so that a lot of people will want to use that application, exactly like what happens in the proprietary software world. However now, the customers have the source code, like what happen in the Free Software world!
It's not perfect, but although this type of "open source" (Some would say that I can't call that "open source", but it's not as if the Open Source Initiative had a trademark on the term (like, for example, "organic"). If I want to call that "open source", it's my choice) software isn't in the same ballpark, "freedom"-wise, as Free Software, I think it narrows a painful gap. That is why it is the direction that I'm taking with Hardcoded Software today.
Selling Development Time
I tend to agree with Free Software proponents when they tell us that code shouldn't have owners. While I certainly don't agree with everything M. Stallman says, it doesn't mean that all his claims are baseless.
The extra clause that has been added to the BSD license in E Text Editor prevents people who didn't purchase the application from using it as long as the copyright lasts. Therefore, even though the code is public, the company's revenue stream is still based on code ownership.
What I want to do, rather than sitting on intellectual property, is to sell my development time to a large audience and this, after the work is done. Therefore, the license I use for my software is similar to E Text Editor's, but with an additional clause that causes the code to become licensed under the general BSD license 2 years after the commit. What it means is that the code you checkout today will be entirely free after 2 years, even if I stop publishing the source (you still have the licensed copy you check out 2 years ago). Although the copyright law is still used to encourage payments from users, there's a shift in what is actually bought by the customer (maybe not legally, but in principle, yes). Rather than buying the right to use my "intellectual property", the customer is buying a share of the last 2 years of work invested in the product.
Selling development time rather than licenses affects more than just users, it also affects external contributors. With E Text Editor's model, developers give away their time to a codebase that is owned by the Open Company. They are then promised a fair share of the profits, a share that will be determined by their peers through the Trust Metric system. There's no problem with that as long as you believe in the fairness of the system. For people who don't believe in it, there are very few incentives for them to contribute to such a codebase.
Because I don't want to limit potential contributors to people who believe in an eventual Trust Metric system, my intent is to pay them myself an amount of money we both agree on before the work is done (I'm thinking about a bounty system here). I think it's fairer than a promise of a fair share of future profits.
Moreover, I don't want to tie external contributors to my development decisions. I certainly don't intend for the development of HS's applications to become a free-for-all playground where tons of features are added by tons of people without a clear direction of where the development is going. Because of that, it is very possible that I will end up refusing some suggestions. If that happens, because the codebase becomes completely free after 2 years, a fork is always possible. Potential contributors can thus confidently invest the time necessary to learn how to work within that codebase, knowing that this investment can't be destroyed by an arbitrary decision.
Among the comments following E Text Editor's move, several of them mentioned the problem of "piracy" (copyright infringement). With the code openly available, wouldn't it be trivial for someone to just strip the code limiting the application when in demo mode, then just run it for free? It turns out that Alexander chose to keep the core of the application closed, thus making such modification harder to make. However, in HS's case, there is no such limitation. All the code is open, including the code limiting applications in demo mode.
So, am I doomed to failure, my beloved code being greedily "stolen" from me by the web mob? I don't believe so. I think that most people are honest. HS applications' demo limitations are trivial to circumvent, yet I still sell them and have been for years. Sure, there are dishonest people. There are also broke (students) people. Those people don't pay, sure, but I much prefer to forego this revenue than to invade the privacy of the honest customers.
With the code open and the demo limitations being trivial to remove, the situation is the same as it was before, and I'm confident that honest people will continue to buy HS's applications.
Why bother with demo limitations at all then? Although I believe that most people are honest, I also believe that most people are lazy (yeah, we all know we are), and will do whatever is the easiest. If there are no limitations, it's much easier to download the application, use it, and never pay (you have to get your credit card out and everything...). If there are demo limitations, you have the choice between buying the application, or checking out the code yourself, know Python, locate the demo limitation code, disable it, then build the thing. On top of that, while the code is building, you have the time to tell yourself "I'm being dishonest", because you are actively doing the thing (rather than just telling yourself "I'll pay them later" and then forgetting about it).
Of course, all of this is based on the assumption that most people are honest. However, if this assumption is wrong, I'll be more sad about being revealed the true nature of people than about losing revenue (I don't think I'd have problems finding a job if that happened, so it's not as if I'll starve or anything).
I'm making this move with the hope that more developers decide to do the same. I think it would be awesome. With an approach like this, software development would normally have two distinct phases:
Active Development. A developer has a good idea, starts working on it, and when usable, publishes it under the license I have just described. If the application is any good, the author will attract some customers, who will give the author enough money for him to continue the development of the application. With some luck, some other developers will be interested in working on the application, and the author will have enough revenue from sales to pay those developers (using a bounty system on tickets being the easiest way I can think of).
Even after 2 years, if the application is still in active development, the users will still pay for the application because the current version will be much better than the 2 years old version.
At any time, if another developer disagrees strongly with the direction the development of the main branch is taking, he can fork the project. He can either fork from 2 years old code, or fork from the latest code. If he forks from the latest code however, he'll limit his customer base to a subset of the original author's customer base for a period of 2 years.
Because of the effort required to fork a project and invest time and money in making your product known, it should, most of the time, make more sense for a developer wanting to work on the project to collect bounties rather than to start a fork. Of course, this requires that the original author is fair and honest about the way he handles bounties.
Mature Project. After a while, there will be less and less improvements needing to be made on the application. The price of the current version would then start to lower, as the difference with the free version narrows. Eventually, the application will either be free or be sold for a low price (to keep fueling the bounty system and to pay whoever maintains the builds). It won't matter either way, as the original author will have started new projects and won't financially depend on his mature projects. The bounty system would still be in place, so there would still be incentives to improve the application, if there's a demand for it.
With this development process, normally, developers will be paid (maybe not for small patches, but for significant work, yes) fairly for their work. This way, there will be soon-to-be-free code that will be produced that would not have been produced otherwise. Therefore, although I'm sure that hardcore GPL proponents will have contempt for this approach, I think that in the end, it helps the Free Software movement by bringing some more code and money into it.
Hardcoded Software Is Stepping In
As of today, most of Hardcoded Software's source code is being published under this license:
Copyright 2009 Hardcoded Software Inc. (http://www.hardcoded.net) All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Hardcoded Software Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. * If the source code has been published less than two years ago, any redistribution, in whole or in part, must retain full licensing functionality, without any attempt to change, obscure or in other ways circumvent its intent. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This license is used for every HS's application. For libraries however (hsutil, hsfs, hsmedia and cocoalib), plain BSD is used because the more this code is used, the more chances I have to get patches back. There's also an issue with the PyQt dependent part of HS's applications. Although this part of the code is licensed under the same license as the rest, it is dependent on PyQt, which is dual licensed. If you don't possess a commercial license to PyQt, you must use HS's applications with the GPL version of PyQt. This doesn't cause any problem, unless you start re-distributing the code. To have the right to re-distribute the code, you need it to be GPL compliant, and the HS license is not GPL compliant. This means that unless you possess a commercial license to PyQt, you can't send any PyQt-dependent-HS-licensed code to anyone, including Hardcoded Software. It's unfortunate for potential contributors to be restricted like this, but then, it only affects the GUI layer of the Windows versions of HS's application. Moreover, I have faith that PyQt will end up being re-licensed as LGPL.
As for external contributions, I'm certainly open to it, although I'm not even sure there's any interest from external developers to work on HS's applications. This is why I prefer to wait a little bit before beginning to design a bounty system for HS tickets. If you're interested in working (not for free! if you offer something I need, I'll pay for it) on this code, please let me know about it
That's it! It's a risky move, but I think it might be the beginning of something pretty nice. If more software were released under such a license, it would create a lot of freelancing opportunities in the generic software development field, as well as create a lot of free codebases to build new projects upon. In any case, don't hesitate to let me know of what you think.