Slashdot Mirror
Negotiating Pay for Open Source Work?
OpenSourceforMoney asks: "For about nine months now I've been working on an Open Source software project; the first release was five months ago. It's reasonably popular given its age -- several hundred users at least (users, not downloads) -- but despite my best attempts, I've been unable to get even a few dollars in donations to help support this (and being a student, I really need to get some money from somewhere). Now suddenly I've been approached by a company which wants to pay me to continue working on this project. How should I handle this? Should I ask for an hourly rate, or should I come up with specific targets and attach prices to each? How much money is it reasonable to ask for, for doing work which I'd end up doing (albeit more slowly) even if I wasn't getting paid? How have Slashdot readers handled the transition from working on a project for fun to being paid to work on it?"
$25 an hour and they provide the hardware. flex time. try and get benefits too.
this sig limit is too small to put anything good h
They are solid. Either a feature is present and functioning or it's not. No need to quarrel over hours.
Yep, I never spell check.
More incorrect spellings can be found he
Don't forget that if you start getting paid for your work it opens up a whole new slew of responsibilities. You might not be able to slack off as much as you like, etc. It gets harder when you have to answer to someone.
on what this piece of software is, and how valuable it is to them. if it would cost them $20k to design it themselves and would be worth it for them to spend $5k for you to do it, then quote them that. but you need to sit down with them and come up with a approx time which it will be completed, how many hours you'd be putting in, etc. also, is there other software out there that does this, compare what you would charge to what it would cost to buy commercial software. will you be providing support, or development only. there's more than just what should i charge, you need to do a little investigation into what the company wants and what's out there, and how long it would take you to do this
Cyberbite Networks - Web Hosting, Dedicated Servers & Colocati
If they are going to be benefiting from your work (attaching their name to it somehow), it might be good to get a peice of the company. Or profit sharing. Something. Sure the dotcom era has left a lot of people sour about working for shares in a company, but if you believe in the company, it could be worthwhile.
The more important the project is to you, the more you should ask. The less it matters (personally) the lighter your demands. As an artist, I charge more for paintings I personally favor. Do not try to negotiate a payment for what you have already given away freely by inflating your offer; you've given it away, and there is somebody else who could continue your work more cheaply. (Even if they are n't looking for one, it leads to resentment, as it's tacky.
Whatever you ask for, choose the offer that leaves doors open for the future. Avoid killing a golden-egg goose. If you are getting paid to pursue what you would do of your own accord, you are getting a good deal. The dream of capitalsim. And if the company you are working for thinks it's a steal to have you develop for them, so be it!
Looks good for your age..
Not that I've ever been in your situation, mind you. My life consists of paid projects I wouldn't choose to develop on my own to subsidize unpaid work on projects I love. Consider anything you get a bonus.
That said, there's no reason to tell your client the whole truth and nothing but the truth. Focus negotiations on the value your software represents to him. If your software is worth more to him than he is paying you to do the development work, the deal will get done. Let him know you would keep working on it for free, and even if he wants to pay you to speed things up, you won't get as much. Let him know that due to other obligations, you were thinking of maybe dropping the project, or at least drastically pulling back on the number of hours you can contribute. Encourage him that for the right price you can afford instead to drop your other obligations and make this product really kick ass, which is of course what you would prefer to do, if only it could be facilitated.
-- ShadyG
Nerd Rock In Progress
If you're in it for the money you'll do better hourly.
If you just need $x amount of money to keep going and you're happy with that you can bid by the project and do fine.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Even though you may indeed deserve far more than the $0 you've been paid so far, you can't expect this one company to foot the entire development bill.
Don't try to charge this single company full price for your work, or the use of your program is likely to become more expensive to this particular company than a competing (and probably more feature-complete) commercial package. If your software's good enough to have attracted hundreds of users and a corporate sponsor, it'll probably become good enough to attract even more sponsors.
What you don't want is for the one corporate sponsor you've attracted so far to come away feeling as though you're trying to saddle them with a development bill that should have been more broadly distributed.
In summary: you're on the right track, but have patience.
I was in this situation a few years ago, when a company wanted some mods done to a camera-control library I had written and publish on sourceforge. Because they were a well-funded company, I charged them an hourly rate. However, because they were funding an open-source project, and because their changes were fairly small, I was willing to give them a break. I charged $50 an hour - less than half what I would have charged on a project for proprietary code.
I'd suggest you take into consideration who the company is, what they want to do with the code, and what their financial situation is. For example, I wouldn't charge a big, well-established company the same I would charge a non-profit.
Also make sure the company understands who owns the code you produce. Many companies don't understand how open-source licenses work, and might assume that, because they've paid for it, your code belongs to them and doesn't continue to fall under the restrictions of your chosen license. Understand your license fully and make sure the company that's paying understands it too. (Just to avoid disputes in the future, you might want to capture that understanding in your contract, or in a side agreement.)
Make sure it is explicite that the code you write is your Copyright. Make sure the clasue Work-for-hire or anything to that effect is not in there.
The difference is major. If you do it as work for hire, they own it. If you do it and own the copyright, you are building equity.
Open Source Identity Management: FreeIPA.org
Make up a spreadsheet of features the clients want, and estimate out the time it would cost for each, and as most do, add a little flex for unexpected details (which, luckily if you are the developer of the initial code, you shouldn't run across too much of).
/. to estimate how much you should charge, without knowing more about the project itself, so the best I can give is this rough estimate. Try to keep in mind that hourly is the easiest as far as getting paid for any extra things that crop up, but the timelogging can be a real pain in the butt, and justifying time over an initial estimate can be too. /. etc etc, so really a per-unit basis might be the best bet.
Then, once you've got that down, you can either estimate your charges based on:
a) Per-unit basis (charge per X feature)
b) Per-hour basis
c) Overall project basis
You can't really expect
For myself, I rarely work straight-through hours on contract projects, but usually stop to grab coffee, check
That way, anything extra they suddenly think of that they want (and if you have ever developed corporate software before, this is more common than not) can be tagged in later, and you can also set cut-offs for various functionality/features.
Also, get paid in installments because sometimes good projects get cancelled by bad budgeting. Thankfully an open-source project at least doesn't die in this scenario, as nothing is worse than watching your "baby" project die at 80% before reaching fruition.
Negotiate a contract
Make a rough estimate on how long it will take you to do something, double that, multiply that by $100/hr and ask for that. Offer fixed deadlines for what and when you will deliver. Make sure acceptance test is spelled out. Make the deadlines easy to hit, and deliver early.
If you can't negotiate this, ask for a small fixed price to come up with a detailed proposal - say $100. You should already know approximately what they want. Then spend a day or so going back and forth until you can come to an agreement.
Maybe negotiate a bonus to have it done early.
The key point of your negotiation is who will own the 'work product' when you are done. If it's you, you can release it open source again.
TODO: create/find/steal funny sig.
Companies interested in already coded starting points that just need a few more features (most GPL/OSS projects) will have a cutoff point as to where they would:
A. Start from scratch in house
B. Expand upon the source with in house team
C. Bring someone (contract/consultent) in to bone up on the code and fork it to their needs
D. Find a different package that meets their needs
The fact they are looking to the original team to do it means that they are looking for the most efficient (both in knowledge and cost) solution out of the gate.
If the cost remains cheaper than it would be for them to do it "in house" or bringing in a contractor -- then that would be the sweet spot for all involved.
(+1 Funny) only if I laugh out loud.
of getting payed to be creative in an enviroment geared to quantify "production." So many worthless widgets produced an hour at so much value per widget and such.
You ain't alone. This is an issue that musicians, artists, conventional authors etc. have been wrestling with for centuries.
Your own quandry gives all the evidence needed that there is no clear answer; and where there is no clear answer people on both sides always feel "funny" about the whole thing. Feeling "funny" leads to discontent and acrimony.
Therefore the ideal solution ( which is to say as reasonable an approximation of the ideal as you're ever going to get) is always highly dependant on the very nature of the parties, which is going to be different in every specific case.
Again, as example, you've actually gotten a lot of good advice already, based on real experience of real coders, and a lot of it conflicts. Different parties, different results.
I'd suggest you go to the people who are relevant to this discussion ( the people offering you payment ) and telling them your desires and fears over how to arrange this, ask them their own desires and fears; and then see if you can come to an agreement up front as to how best meet those desires and alleviating those fears.
In short, talk to them kid.
( And a lawyer never hurts. Trust, but verify. You can be damned sure that's what they'll be doing)
KFG
It is often difficult for those who are not used to billing their time to accurately assess the amount of time a feature will take to implement, including time costs such as requirements definition, maintenance etc.
When I started consulting, I took the amount of time I thought something would take and quadrupled it, which seemed to be about right. After many years and much experience, I only double it. However, the point is that even for experienced consultants, predicting time committments is an art frought with uncertainty.
So to prevent yourself from getting into situations where you end up taking four times as much time as you thought you would take and consequently only making a quarter of the rate you thought you would make on an hourly basis, simply charge them on an hourly basis.
A second recommendation is that you not sell yourself short in your hourly rate. As a student, you may not have ever earned $25/hour. However, you have unique knowledge of the product and are doubtless a talented programmer with marketable skills. Don't be afraid to ask a bit higher than you may otherwise be comfortable with and be prepared to negotiate to a midpoint if they balk.
A third recommendation is that as an independent consultant, you document your activities much more thoroughly than you otherwise would. Write down the requirements they specify. Record your hours and what you did during the hours you bill them for. As someone who is not a regular employee, you should endeavor to be able to justify any and all billing questions or other decisions in a way that regular employees would not need to.
Finally (and this is perhaps the most important point), do not let them convince you to sign over your intellectual property as a condition of your employment or take full ownership of intellectual property you create in their employ in a way that compromises your project. Read everything they ask you to sign. Take documents home to read them over, take them to a lawyer, take them to more experienced friends and solicit their advice. If you are uncomfortable with something, cross it out, initial it, and ask a company officer to initial it as well. Everything is negotiable, including intellectual property arrangements.
Good luck!
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
If you're the recipient of money, you don't normally want to be the first person to call out a number, so ask the giver of the monies how much it's worth to them. This will also keep you in a reasonable 'ballpark' figures. For instance, if you answered back that it would cost them $150/hr, when they were only wanting to give $25/hr, that's quite a difference and the company may just give up and decide not to pay you alltogether. The same is true if you decide to do it based on features and you say 'Feature X will cost you $5000' and they were only thinking of maybe $500. If you're a busy college student it may be more difficult to keep track of individual hours, so you may want to consider a pay-per-feature plan. It may also be easier for the company to think of paying you by the feature and then they are basically donating lump sums of money to your project.
The moral is to try and get a number out of them first and then negotiate from there. If the number they throw out is completely unreasonable, let them know and (more importantly) let them know _why_ it's unreasonable.
I hope this helps, congragulations and good luck!
Things you think are in the Constitution, but are not.
I want to know that I can pay you $2K to build me a furtzwangler, and get $3K's worth of value out of it. I don't want to hear about how your PC needed to be reformatted (in my time), or how you looked at a cool new solution to a particular design problem (in my time) or how you had to rearchitect your OO persistence layer using the gesundheit design pattern.
It comes down to risk : software development is inherently unpredictable. Someone is going to have to take a risk - will the features I asked for take 6 weeks, 6 months, or 6 years ? You are in a far better position to estimate the duration of the project than I am, so it's only fair that you bear the risk.
Of course, that assumes that I am not a psychopath who changes the requirements every week and "forgets" to tell you it also has to run on the Amiga platform. That is the risk you bear - you might be able to build the required features in 6 months, but not if I keep changing my mind....
So here's what _can_ work as long as there is an amount of trust between you and the company who want to pay you.
This allows you to reduce your risk by not allowing the client to change their mind once you've agreed your current iteration's scope. As the scope of an iteration is likely to be relatively small, your client does not have to make a big, irrevocable decision about what they want exactly so you can do a big complicated estimate. The risk is effectively shared.
By seeing how much you get done in your iterations, you get a way to adjust your prices in a way that reflects reality - if it turns out you had to work day and night to complete your iteration, you need to charge more (or reduce the scope of what you take on in an iteration). If you have time to spare, you can take on more in the next iteration.
It's all very well in practice, but it will never work in theory.
Wow, a lot of folks love charging hourly rates.
:)
Don't do it. Start with a fixed rate deal, and then if they start wanting all sorts of stuff do hourly rate. But a fixed rate lets you spend the time you want where you want. If you do hourly, they are much more likely to pay attention to how you spend your time. Don't ask for rediculous amounts, $5k is a good starting number. Get enough to live. The fact is, you would do this work for FREE
If the company expects that their contract will be your focus, $1000.00 per day is a reasonable day rate in my field. It's close to the $100/hour other posts have quoted. Plan to drop out of school for the duration of the contract. If you're a grad student, talk to your advisor. He might be willing to keep writing ``satisfactory'' on your progress reports while you work exclusively on this.
If the company wants to let you own the code, I'd suggest working relatively cheaply. I might let them bargain down from that $1000 per day. As another post said, you're building capital. If the company expects that they will own your output, then $1000/day is too low, in my opinion. When you're done, you'll have nothing but the money, so it had better be a BIG pile. After all, this will monopolize your life, you're putting off graduation, and so on. Either way, make sure that ownership of the resulting code is clearly spelled out in the contract. Hire a lawyer to review the contract.
Finally, have you talked to your university's legal department? Is there any way that this project could belong to the Uni? Are you sure about that? If you are an undergrad, you are probably in the clear. If you are a grad student, there is a very good chance that ALL your work is the property of either the Uni or some granting agency. If this was part of work you did for the Uni, it is almost certainly theirs. I'd ask for permission to release it under your favorite Libre license BEFORE I mentioned the commercial interest. Most Uni's are VERY interested in exploiting their ``intellectual property''.
Above, I told you to hire a lawyer to review the contract. Do NOT depend on the University's lawyers to do this for you. They are working for the Uni, not for you. Their responsibility is ONLY to the Uni, and if you get screwed, tough. If you're not paying the lawyer, he's not on your side, period.
See what I've been reading.
If they approached you, then they already have a pretty good idea how much money they're willing to spend on this project. So, start there. Find out what they're willing to spend, and then negotiate how much work and what kind of work you're prepared to do for that compensation.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
they approached him because they liked his work. never undersell yourself. if the price is too high, they'll tell you and you negotiatem they wont just drop you.
tasty electronic music vittles
Many years ago, (mid 80s) a friend of mine was working at a lab which, among other things, had a small handfull of UNIX boxes (SGI, SUN, Vax). He managed to finagle me the right to use the equipment in off times to do some of my own computing research (strange sorting techniques, mostly).
While using the machines, I noticed that there were some problems with the way that they were set up, so I also spent some time cleaning up the admin (for whatever reason, I also got the root PW).
In time, his boss found out what I was doing and he came to me with a speech along the lines of: I notice that you've been doing some work on our machines, but in doing some inquiries, it seems that you're not a member of this lab this department, or -- for that matter, not even a current staff or student at the University. This means that if something were to go wrong, theres nobody who could really take responsibility for you being here or what you're doing, and I really don't have the right to ask you to do specific things.
So either you're going to have to accept payment for what you're doing here, or I'm going to have to stop comming here. With some surprise and shock, I chose the former option. He then asked me how much I wanted to be paid for my time.
I quoted him a number which was a bit over twice the minimum wage, and he frowned at me. After thinking for a moment, he offered me a different number -- about twice what I'd offered him. His explanation was that he wanted to pay me enough to ensure that I wouldn't be hired out from under him by the first yokum to come along.
I think that it's very human to underestimate the value of the work that we do -- especially when we enjoy doing that work. All I would really suggest is that you trust that they see value in the work that you're doing, and they know far better than you how much money it's making them (My guess is "lots"). Be willing to stretch yourself in accepting that valuation, and asking enough that you're not regretting the decision later and don't have to make a pained choice later on between staying with a project that you enjoy or going off to a 'real' job that might be less enjoyabe, but would better support your lifestyle.
Free Software: Like love, it grows best when given away.
Dude...
You are doing Windows programming for dirt.
How are you going to hurt your reputation?
Contact the guy.
You *think* your main selling point is your performance, it isn't.
Your main selling point is $9/hr.
If you want to change that... contact the guy.
--Phillip
Can you say BIRTH TAX
Ouch. Sounds like your company is jumping on the bandwagon without checking with the driver to see where it's going.
Of course, this assumes that the controlling interests in your company are smart enough in the field to recognize shoddy work or not. Bugs are bugs, but a lot of the problems are internal -- such as poor, undocumented code that, from virtue of its own crapiness, result in increased costs of updates and management.
My advice is 1) before they shut down your facility, document the entire experience, samples of quality code, ease of communication, east of testing, etc. Later on you can validate your complaints with real-world examples.
2) as much as you might not like management, make every effort to separate yourself from the programming side (don't go fixing the code yourself). This will both save you from any blame that might eventually get passed around, and keep you from winding up in a dual role of manager and programmer, although only getting paid for one.
3) Especially if things look like they're not working out well! Keep careful track of all costs (as many as you can get your hands on) before and after. The current cost of running the facility, the cost of closing the facility, cost of moving people, cost of the new development, cost of debugging/testing/etc. the outsourced development, and the estimated cost of restarting your development facility. The goal is, before too long, going to the upper management and having black-and-white proof charted out, and being able to say, "Due to increased problems with our development pipeline, our theoretical savings have become additional costs. Unless this activity is stopped by %%DATE%%, out benefits will become costs and will continue to degrade. The quality of our product will diminish, and our returns will dissappear into the red."
Good luck
Punctanym: alternate spelling of words using punctuation or numerals in place of some or all of its letters; see 'leet'
Indian programmer are, on average, just about as good as US programmers. Some are great, some are terrible. But it's not nationality that does it. Same goes for Russian, Chinese, South African, or any other programmers mentioned in the thread. I've had plenty of problems with US-born programmers too; it's nothing special.
What is a lot more likely is that hoggoth's outsourcing woes have to do with the *outsourcing* part of it. If you dump code on people without adequate specs, documentation, and yes, supervision, you are not going to get something good back. That fact has little to do with how much you pay them, in fact. And it gets even worse trying to move a project from someone who is intimately familiar with it to someone who has to scramble to figure out what it is/does--not that you always have the former to start with, but you always get the latter when you outsource.
Yours, Lulu...
Buy Text Processing in Python