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
I'd charge by the hour. That way you can work on it whenever you have the time (I'm assuming you're still a student). Keep DETAILED records of when you worked on it and what you did during those times, so they can't come back later and claim fraud. Good luck!
-jls
Techno-pagan
1. Start open source project.
2. Ask slashdot why I'm not getting paid.
3. ???
4. Profit!
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
Which project is it?
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
The way I look at it is that you should charge at an hourly rate requisite with your experience and education. I don't think open source software should be treated any differently than other software projects. That is how it works at my company (generally). We also try to reward contributors who don't work for us on a full-time basis as frequently as possible.
Then again, if the company that wants to retain you balks at that price point, then I guess you have re-adjust your sights....
smd4985
just send invoices to you clients for $699. Some of them will pay without bothering to find out what they are paying for.
New year Resolution: Don't change sig this year
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.
A company will not pay for time that they cannot audit you for. (Forget about filing claims at your local workforce/labor commission to collect for you) The best option is to have them pay on delivery of features & milestones. Well, maybe half up front, and half after b/c you don't want to get cheated and you need immediate motivation & relief. That way is a good way to compensate everyone and build trust between both parties. After a while of doing that, and building a reputation with them, maybe you can move to a different compensation system.
Hourly rate if you can. Projects ALWAYS take long than you think. Fixed price negotiations are generally bad news for "small shops" and individuals. I've got 22 years under my belt, and this is my experience.
--Slashdot: News for Turds. Stuff that Splatters.
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
You should bid the project out in it's entirety then sub-contract it to india for 1/5 what they are paying you. :) EVERYBODY WINS!!!!! :)
They get their project
Some indian Programmer gets paid a great wage for his market
You get your cut and can do something else
I think BARE minimum is pushing it there. Its no wonder companies are outsourcing to India. $125/hr is like average to high market place.
"A synonym is a word you use when you can't spell the word you first thought of." - Burt Bacharach
Don't sweat the benefits and crap. If you're a student, you've prolly already got health insurance...especially if your folks are still listing you as a dependent.
Companies are much more willing to pay big $$$ to someone they don't have to give benefits too...so $50 - $100 per hour may not be out of the question.
Also, if you're only talking a relatively few hours, ask for more. i.e. if it's only 10 hours a week, $100/hour get's you a grand, while 20 hours a week at $50 gets you that same grand...it all looks the same on the company's monthly budget.
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.
You take a big risk if you agree to a fixed price contract. While it might seem like there is potential to make more by working efficiently, it doesn't usually happen that way. Estimating how much time a software project will take is *hard*, much harder than it seems. Even if you have experience making those kinds of estimates you are likely to be significantly wrong -- usually too short. Then there is the question of whether a feature is actually done. Particularly if there isn't a well documented requirements document, there can be a wide gap in expectations.
So you can chop the project into tiny, easy-to-estimate pieces and write up a huge requirements document to manage your own risk, or you can just take an hourly rate and code. I know which I'd rather do...
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 it hourly. Rates, $30-$40.
Important, do not accept anything without understanding your rights to the source and the derivitives they create from it! You might be openoffice.org (example), but Sun is packaging it at $70 per copy.
Make sure it is spell out what they are doing with it.
Make sure they don't gain the right to take you off the project if you don't meet their deadlines for releases.
Make sure that if they see Intellectual Property(IP), i.e. patent potential, that you do not sign your right away. If they are funding you, you could loose your rights to IP they pay to patent.
Make sure you have the right to "hire and fire" and personel they give you.
Talk to a CPA, yours not theirs. You want to make sure you are set up correctly for tax purposes. If this is open source of for profit, you are a business, if you are doing this for the good of mankind and envison your self as a non-profit, there are tax issues on either side of this.
If you are a business, they can loan you a machine. If you are a non-profit, they can donate the machine to the non-profit.
You need to think about what you want in the end.
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.
I have a similar project (DataVision, many hundreds of users, 7 languages, over 30 countries). Two different people have paid me $1K each to implement major features.
Transcript show: self sigs atRandom.
Consulting agencies tyically charge significantly higher rates.
Check the details of the contract, i.e. who can terminate it, with how much advance warning, how conflicts are resolved, who pays for arbitration, if any, who pays for travelling, and so on. I always insist on the company paying arbitration, and paying my travel costs for arbitration, regardless of outcome. It lowers my risk significantly, and I have not yet had any trouble.
Stephan
Whichever way you choose, you've made one thing clear: you only have a limited amount of time to do the work.
Besides pay, you should also consider what happens when:
Contracts are there to define what your responsibility is, and the responsibility of another party. It's important to know what would happen if you were getting close to meeting a target, and the other group backs out - would they still have to pay you? If you were paid hourly, would half-written code be worth anything?
It's okay for two groups to be unhappy about a situation, but if you have forgotten to specify the responsibility of each party, then things get nasy. The worst thing that could happen is the project dies... okay not the worst, but it's up there
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
Don't go hourly. Unless you are super-fast, everyone will be unhappy.
We all know how something seemingly trivial can suddenly turn into a time sink when it doesn't go exactly as planned or when your new employer asks for something a little different than what you planned.
So break your project into sections. Define very clearly what the section does--its features, links into other sections, operating platforms, testing process, a timeline for completion, what parts of the scope your new client can define (and when), and any limits.
Going through this somewhat tedious planning and defining part will make both sides of the transaction comfortable with what's being delivered and when--and it allows you both to note any potential problems. It also gives you both something to point to when the project is changed (you can ask for more money) or not delivered according to scope (they can withhold payment).
To price the section, I estimate the time it will take, add 10% because I usually underestimate, and multiply by my hourly rate. That's the fixed price. If it takes me longer, I lose. If I work faster than I expected (ha!) then I win. Usually, I'm right about on time.
(My hourly rates vary based on the type of work but range from 3,500 yen to 10,000 yen/hour. I do love those 10,000 yen/hour jobs but they are few and far between.)
If your section that's going to take months and you need rent money, then work out a payment schedule with target dates for certain key goals within the section.
In the US, contracted work is usually done with a 1099, in other words, you're not their employee so you won't get any benefits and you'll have to pay self-employment taxes.
I run a rather successfull Open Source project. phpBB (bulletin board software, http://www.phpbb.com)
I've had more offers of money then I can shake a stick at. People have offered to pay us for development, sponser our website, and just buy us outright. I've turned them all down. Why? I don't trust corporations...
Ultimatly the people paying you to develop are going to expect something back, and most likly that will be ownership of your code and the right to dictate what you do with it.
If you do accept their offer and take payment for your Open Source work make DAMN sure you're not signing away any of the rights to your code.
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.
It's pretty straightforward - you want all you can reasonably get out of them. They want to pay what's fair, or less if they can... so the intersection of that is, what's it worth to them?
They probably won't want to tell you that - they may not know themselves, right now. But without more information on what your project's about and who the company is (not to mention what work they expect done), it's difficult to speculate on what the value is. It may be up to you to figure out what benefit they will receive from your work, and base your compensation (hourly or package-deal) on that.
How do you do that? I dunno. Track down other people they've funded, or former employees (or maybe just some people lower-down in the food chain than whoever contacted you). Look up their financial reports, try and guess how much your work will affect their business. For example, if you're writing a driver for a product of theirs, find out how many they sell per year and try to guess how many more they'll sell with your driver available. It's probably worth your while to do some legwork.
Or just make it an hourly rate. But I'm not always comfy with them; some days I do a lot more work per hour than others...
Perfectly Normal Industries
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
The second half of your legitimate complaining was about non-IT industries and unskilled, non-professional labour which has nothing to do with outsourcing a programming project.
As for the IT industry, well, what would you have the Indian IT industry do? Not advertise its services? Shut itself out of the largest IT market in the world? Say, oh, no, we won't accept offers from the USA because it's not fair to workers there? Puhleeeze. Canada, for example, became a great IT (especially programming) resource because it had an educated workforce, able and willing to work for cheaper than Americans. The lasted for some time, but the Canadian IT workforce has hit similar slowdowns as the Americans now also. The difference with India is even greater. Indians found a market where they can do comparable work (I'm not saying better or worse, but comparable) for much less cost. They moved in. That's the natural progression for anyone rational.
The writing has been on the wall for 10 years or more. Robert Cringley wasn't the only one writing lucid books on "The Decline & Fall of the American Programmer" in 1993. Any American who has entered the IT profession in the last 10 years either did their research and knew what the risks were, or simply didn't do basic research about where their IT industry was going and what its competition was going to be. The latter group missed the cluetrain and it was their own fault. This is not news.
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
If you charge by the hour, you are committing to a larger workload. Create a specific list of deliverables (small, workable code chunks) and price each one according to about 150% of the number of hours you anticipate times the going rate of $50 to $75 an hour. This gives your client a fixed cost (which they should appreciate) and you the flexability to work at your pace. You'll have some evenings you'll bust out a massive section and others that are slower but it won't matter if it is a fixed cost. I released three titles under this model and it halted many arguments. One warning... set your timetable within easily reachable goals. Your client will expect a finished (and working) product exactly on the day you promise it. Good luck and welcome to the evil corporate world! AG
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
You have very specific skills and experience that places you in a unique position. If this product is truly important to the company that has approached you, then you are in a highly priviledged negotiating position.
In the Silicon Valley, when I did contract or consulting work, my rates ranged from $80 / hour up to $250 / hour depending on what it was doing and how much flexibility (read: responsibility) that I had.
If you are working from home, when you want and not having to deal with the daily grind of their organization, you should probably charge per "milestone" (e.g. put a price on each feature or bug-fix that is requested). This price should reflect the complexity of the feature as well as the market prices that the target company is used to paying. In general, you should never charge less than $2k for any feature or basket of bug fixes, and never more than $15-20k (depending on how large the feature request is). It is really okay to have a chat with the manager who is authorizing each feature, start by asking "what do you expect to pay for X" and be prepared to gently press him/her higher. Your job is to try to find the highest price for each feature that he/she is comfortable with. If you are also comfortable there, do it.
If you are going to spend time at the company, you should charge hourly rates. These rates should be HIGH in comparison to local consulting/contracting rates because of your unique position as author/co-author of the product that they want you to work on. If you are in northern California or the East Coast, for instance, you should not agree to work on the customer premises for less than $100 / hour. And depending on who you would be working for, the duration of the contract, what you will be working on and the demands placed on you, you may be able to push that as high as $200 - $300 / hour. Generally, the shorter the contract, the higher the rate.
Whatever you do, don't take the "donate your time" attitude that you have in developing Open-Source software and direct it at a profitable business. Giving to the community is one thing, and very noble. But when it comes to business, nobility is derived from profit.
The reason that it can be true that 1+1 > 2 is that very peculiar nonzero value of the + operator
and my mentality has always been that if someone needs the software then they'll pay for it to exist, even if they don't want to sell the source code afterwards. And to a large extent, this works. In fat, it works perfectly. I've never had anyone say "well you're writing free software, so why should we pay you?". In fact, often the software I write is for universities, who would rather release the code open source than hang on to it. This is just the mentality that unis have, I guess.
I wrote a simple IDE extension for an RCS, then contacted the company to see if they wanted me to build it into a full-featured integration.
They did -- so we worked out an agreement. I made a list of small-scope enhancements, and put a dollar amount on each (based on my time estimates and a good hourly rate). Per the contract, I made the listed enhancements, and released the project as open source (which make the source available for any other developer who wants to enhance it for them! nice bonus for them, isn't it?).
Worked out exactly as designed, win-win.
I will mention that just listing an hourly rate is tough in a few ways. You have to keep careful track of your hours, which can be hard, PLUS they aren't sure what they're really signing up for.
It's a good idea to try to keep track of your time (because otherwise your estimates will be *way* off), but giving a single dollar figure for development, testing, deployment and those few bug fixes is better for both of you as long as your milestones are small (because if your estimates suck you don't want to get screwed over too much).
Don't forget to consider stuff in the contract like:
- unforseen *large* setbacks might force you to revise your price/deliverable midway
- only bugs that significantly impair functionality AND are discovered within the first month after release are included in the original contract
- owernership and copyright clearly remains yours; the funds provided are purchasing your time, not the finished product (which will be licensed to them under the same license everyone else gets)
Good luck!
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I currently work for $AU 30/hr (about $US15). This is considered pretty damn cheap, but I maintain that rate because I get a hell of a lot of work word-of-mouth.
Next year (after finishing university) I will have a lot of experience under my belt, a reputation for getting stuff done properly cheaply, and a lot of loyal clients.
I find it quite interesting to see references to "entry level" jobs being $50/hr or $50k/yr. Over here (in Australia) entry level IT jobs are generally around $AU30k/yr ($US15k), although I'm hoping to get around 50-70. Perhaps I should move to the states.
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