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?"
Which project is it?
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.
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...
Software development, in a contract with no benefits? $25 is very much entry level.
$25 (or $51k/yr) is entry level maybe if it's with a big established company giving you benefits, but for hourly contract work, it's not.
My sig is blank, I typed this by hand.
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.
Charging by the hour is tough when working alone because of the record keeping and the feeling that one will be accused of laziness for spending a lot of time at a *seemingly* simple task.
I reccommend negotiating a contract based strictly on an agreed upon task list (with a dollar amount affixed to each task).
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
I've never done less that $40/hr when working on contract. Now my minimum is $50/hr. On most projects I set a minimum time as well. I also give estimates and take 33-50% up front followed by one or two more payments as necessary. If you know your stuff, you shouldn't sell yourself short.
On the other hand, if it's a project you're doing anyway, I could understand taking less. In that case part of your pay is the satisfaction you get. The question is, can you afford that?
t'nera semordnilap
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'll address this issue from the other side. About 1.5 years ago, my former employer wanted/needed to replace an aging application that was shared source. That application had been customized by a former employee, but the original perl source was deliberately obfuscated, and the customizations were an ugly hack, completely undocumented, and had been done by an employee who was later fired.
I found a GPLed project that would meet all our needs except for a couple of missing features. I took that to my boss and suggested we pay the author to add what we needed and GPL that code as part of the main project. This was approved in principle, so I contacted the author.
We quickly negotiated a set price for the features we wanted, and I took that back to management for approval. It was quickly approved, and he got to work on the things we needed. It was a real win for everybody. We got all we asked for and then some, at a great price. Because we were (at that time) the largest deployment of that software in the world, it got the most thorough workout and bug discovery process of its life and many fixes of previously unknown bugs resulted from our testing and use.
It would have been much harder to sell management on an hourly rate. Since I was able to go to management with a list of what we needed and a concrete price to get those things, the deal was approved almost immediately, with no dissent. Every level of management, from my boss to the top, liked the fact that they could put a specific, reasonable price on it rather than an open-ended situation that they would have had with a per-hour contract.
From the sounds of it, you have no idea what the project is worth to this company. In the end, the value of what you are doing is related to the how much money the company is planning on making from your work, and the people asking you to do the work have probably got some number in mind already.
Why not ask them what they have in mind first, before you go and put a figure on the table that may well undershoot what they are prepared to offer.
They approached you - ask them to make you an offer.
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.
Try to find a teleworker contract. ... I would hire you imediatly for $18 ... well I would have a bad feeling ... to rip you off that bluntly.
$9 is ridiculous. Consider to learn Java
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I can't leave. I'm in the middle of a big project and if I leave now, I'll get a bad reputation. That'll really affect my ability to get hired in my area. My main selling point is that I've never had a project fail or get canceled do to time/cost over runs.
This project will be done sometime next year. Hopefully by then the economy will be better.
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
If you do this, then you MUST double your estimated hours. You'll feel bad, because you'll think you can do something in a week, even though you'll charge them for 2 weeks of work as a flat-fee. But don't feel bad -- you will actually take 3 weeks to do it right and end up making less for your time. And in the odd case where it actually does take less time, you can be sure that the company is fine with this because they'd rather pay a little extra for a flat-fee than get an ambiguous hourly "when it's done" contract. Besides, everyone is happy when someone delivers a product ahead of schedule.
My Greasemonkey scripts for Digg &
Why not outsource to Australia, New Zealand, or South Africa. The currency exchange rates mean that you can probably get a high-quality development team for 50% or 60% of the going rate in the USA, and they have a similar standard of education.
Plus, there won't be any of the communication problems that you find with outsourcing to other countries.
Ireland and the UK are other good places to outsource to, but their IT industries (especially in Ireland) are starting to get very large, so good workers are in very high demand.
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.