Slashdot Mirror
Ask Slashdot: How To Get Paid For Open-Sourcing Your Work?
kc600 writes "Say you're a freelancer, using mainly open source solutions. You notice that customers, although they don't object to the whole open source idea, don't see the point in paying you for the time it costs you to properly open source your code. As a result, code is not released, because it would take too much time to factor out the customer-specific stuff, to debate architecture with the other developers, look at bug reports, et cetera. You feel there's something to contribute that many might benefit from. The code would also be better maintained if more people would use it, so the customer's project would also benefit. But you're not going to do it in your free time; you have enough on your mind and the bill is paid, right? What useful tricks can you think of to encourage yourself — and your customers — to properly share code, to the benefit of all, and get paid for it?"
The hard question really is "how do I convince people to give me money for writing software?". Open or closed are just details if it's being sold as part of a provided service.
http://en.wikipedia.org/wiki/Johnny_Appleseed
When I open sourced the programs that had made me some money, but I had no time nor the stamina to keep working on them, I didn't expect to get paid for that.
Instead, I thought of Johnny Appleseed.
The programs that I open sourced, to me, are old stuffs. I could have kept them under closed source, store them in CD-Rs or external hd or old computers, or ....
I could have done that, but if I did that, it wouldn't benefit me, nor anybody else.
When I open sourced those programs, I didn't even know if anybody else wanted them in the first place. I just placed them online, did some advertisement on related sites, and then, let go.
If the "appleseed" blooms, good.
If they don't, well, it'd be the same as I locked them up in CD-Rs.
The most important thing is that I've set them free. Their "lives" after being set free depends on their "fates", or in spiritual kinda speak, "karma".
Once they are open-sourced, they do not belong to me anymore. Now, they belonged to the world.
Muchas Gracias, Señor Edward Snowden !
So instead of a programmer grabbing a Linux kernel, and spending a few days to add a driver for customer specific hardware, you would advocate that he wrote his own operating system instead ?
Mod this up to the skies, please! In my opinion this applies to -everything- forgotten books [I've been thinking about trying to find the rights owners for some of them], forgotten music [same problem, I'm from the 60s there's some wonderful stuff buried] etc. Unhappily, for me, this non-publishing is collateral damage that [in the spirit of Bentham: http://en.wikipedia.org/wiki/Jeremy_Bentham%5D should be increasing the sum total of human happiness and instead lies locked or buried.
The second point, for software etc., is the 'standing on the shoulders of giants' idea. That is, something fairly simple or a few bits can be used to build something spectacular or inspire it. Same point of inspiration idea for music too.
Great post with a great many 'extra' implications, thank you.
On y va, qui mal y pense!
Another poster already called you an idiot, so I can skip that part and get onto exactly why you are wrong. People pay me to write software because they need that software written. That is the best motivation for writing software and the reason why about 90% gets written. The remaining 10% of commercial software is written because someone thinks it's a good idea and that they'll be able to sell finished versions.
Pretty much all of the software that I've been paid to write has been released under a permissive license (MIT, FreeBSD, or UIUC license). This is because there is a non-zero cost associated with maintaining a proprietary fork, which is basically what happens when you make any nontrivial changes to open source code and don't push them upstream. New features and bug fixes upstream may change some interfaces that you depend on and this means that you end up either having a version with known bugs (including security holes), or you spend money backporting the changes to your branch. If you upstream the code then someone else pays for this and it is cheaper for you. In FreeBSD land, we're currently working with Netflix and Juniper to upstream a load of their changes for exactly this reason: they want to spend developer time (and therefore money) on new features, not on keeping old ones working.
More importantly, if you don't upstream your code and it's useful to others then eventually someone else will implement the same feature, but often in a different way. You then either throw away the code that you've paid to have written and use theirs, or maintain a fork that is now radically different to upstream and therefore much more expensive.
As the developer, you also benefit from being able to use the code elsewhere. Everyone wins: your current customer gets a lower long-term maintenance cost, your next customer gets a smaller up-front cost, and you don't get bored implementing the same thing lots of times.
I am TheRaven on Soylent News