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?"

Comments

Wrong question - "how to get paid?" is enough

[dbIII]

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.

Re:Wrong question - "how to get paid?" is enough

[beelsebob]

This is really rather simple... The reason you are getting paid is because you are doing what they want you to do, not what you want to do. If they don't want to open source it... Tough titties.

Sure, have a quick go at convincing them that the project or a subset of it would get them good publicity if they allowed it to be FOSSed, but really... It's their code, they paid for it, so it's their choice.

Re:Wrong question - "how to get paid?" is enough

[chrismcb]

It's your choice too; nothing forces you to work with clients that refuse it.

I didn't get the impression that their clients are refusing to allow the OP to open source the code. They are just refusing to foot the bill for it. I'm also making the assumption that the code the OP is referring to is NOT actually work for hire code, and he actually has the permission to open source it. He is just doesn't want to open source it for free.

Simplest way

[Anonymous Coward]

Don't open source it.

You're in the wrong business

[KalvinB]

If you want to get paid to write software then you're writing it for a company. If you want to write software to give away then stop expecting people to pay you for it. They want something for them. Not something for the world to use. By expecting to just give away their code you're telling them you're not focused on their product for their company. And why would they pay you to write software that a competitor can just use for free? If no competitor would use it, then why are you making it open source?

If you want to contribute to open source then do it on your own time with your own money.

It seems to me the bigger problem is that you're not a programmer, you simply find existing things that kind of do what the customer wants and piece them together.

If you can't write custom code for a client without using GPL code then you're not very good at your job.

And if you can't see the stupidity of giving something away that a client paid you thousands for then there's no help for you.

Re:You're in the wrong business

[slashping]

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 ?

Re:You're in the wrong business

[TheRaven64]

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.

Re:You're in the wrong business

[TheRaven64]

There is nothing in the GPL that requires you to contribute back to the community. The only requirement is that you give the same rights to anyone that you give derived works to that you received. For example, you can take GPL'd code, extend it, and then sell the result to a company, with a contract prohibiting you from selling or giving it to anyone else. They are then free to redistribute it under the terms of the GPL, but they are not required to. The GPL does not require you or them to return any code upstream, only to pass rights downstream.

It's not "your" work

[KalvinB]

When someone is paying you, it's "their" work. They are paying you to build something they own.

You no longer own it as soon as you cash the check for the work you did.

Re:It's not "your" work

[Anonymous Coward]

If you're a contractor, this is something normally specified in the contract. That contract will be specific about who owns what, and when the change in ownership happens. That's usually after delivery and final payment.

I know it happens, but I have never personally seen work done where the contractor owned the end result. You can't assign them ownership of "Oracles Database", but they usually own the code you wrote that uses that db.

Either way, it's a contract issue and should always be spelled out.

Are you or are you not a freelancer?

[Anonymous Coward]

Why should your customer pay you for something you want to do?

You simply deliver them a solution and make sure the code is GPLed. Release engineering you can do in your own time, which when done right is an investment in future business because you can re-use the code for another client, deliver better solutions because you got some (free) help improving the code from random strangers, that sort of thing.

As a foss freelancer, you're much more a consultant than a software manufacturer. Amend your mindset as appropriate.

Re:The spirit of Johnny Appleseed for Everything!

[hughbar]

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.

Tell the company what's in it for them

[bigHairyDog]

I recently successfully persuaded the company that I freelance for to open source a core part of their product line. The part we open sourced was essentially the engine that powers several other products. I had a whole page of benefits prepared, but the main one was this:

"Your developers don't seem to realise that the core engine is supposed to be a general purpose platform, almost like an operating system - it needs to be very well documented, and it absolutely can't have any code in it that is specific to one of the applications that runs on it. If you open source it and give it its own website and code repo, your developers will finally understand what it is, and stop dumping application specific code into it when then need to implement a new application-level feature. This will save you time because you won't have to be constantly refactoring application code out of the platform."

Also, "open source is cool, and having an open source product will make it easier hiring new developers" seemed to go down well.

Open source it the second time around

[dhasenan]

The first time you implement something, you don't know there's a market for it. You write something that is very specific to your customer's needs.

The second time you are asked to implement it, you have a known demand, and you have a chance to resurrect the old code and make it better suited to a wider variety of uses. You can charge the second customer the amount it would take to implement from scratch, and use that time to clean up and prepare your previous work for their purpose and for general audiences.

Don't sell project itself but its future

[cronostitan]

I have been in the Open Source business for almost 10 years now and I am leading a big open source software project which is completely self-sufficient.

From my experience what you need to sell is not a 'Please open source this software because other will benefit from it' but a 'Please open source this software because YOU will profit from it - in the future'. Open sourcing a software is usually a bet on future option, like a stock option you are creating which needs constant nurturing.

Tell the customer that with a regular maintenance fee he might be able not only to help you support him (in case of problems/bugs/general support), but also will be able to extend it with possible new features with no additional costs (beyond that maintenance fee).

The 'do it for the public common good' is certainly weighing in on your suggestion but certainly a future investment and return is the key point. At least this worked for me/us. Usually if additional features happen they will be so happy and donate on top, too.