Slashdot Mirror
How Do I Get Open Source Programs Written For Me?
An anonymous reader writes "I am a biomedical researcher interested in having general-purpose, scientific programs developed and released as open source. Interface design and reusability of the code are of primary importance to me. For my purpose, Cocoa applications relying on Core Data seem to be the best way to get the job done quickly. While I have some programming experience, I have few connections to the industrial world. So my question to Slashdot readers is: how do I find someone (individual or business) to write high-quality programs? Are there reputable contractors experienced in Cocoa? What sort of rates should I expect, to use as a starting point in negotiations? Would a requirement that programs are released as open source make it more or less difficult to find someone to do the job?"
Simple as that.
Getting paid is, for most developers, a "personal itch" worth scratching.
The opinions stated herein do not necessarily represent those of anybody at all. Deal with it.
That's the basic rule. Based on what we pay for our contractors (Qt experts -- they are really hard to come by), count on between 600 and 1000 euros a day.
Perhaps you could contact a University with a good CS program, or something of the like. You could fund a few grad students to develop your program for beans, with the stipulation that the source code be GPL'd. Grad students can be cheap, believe me - I am one, and I make a whole lot less than minimum wage.
Quiz: True or False -- On a scale of 1 to 10, what is your middle name?
There are a few things about this blocking your path to open source success ... and even then, it's not guaranteed. So right off the bat, if you're depending on this to get a job or research done, you might want to exhaust all other options (footing the bill yourself/coding it yourself/seek help in your department).
... and I'm not a fan of the cost associated with OSX. But if this is a hard set requirement, you're winnowing down your possibilities. Just get them out there, put them on Sourceforge, post them here, get eyes looking at them.
... is this what you are interested in? I recommend your first step being to approach a friend who is a system engineer (again, seek help) and drafting requirements for your initial program. Once you have that, it will both make development very easy to do via open source and help you concrete your end vision.
First off, the Cocoa requirement reduces your target development community substantially. Is this necessary? Are you opposed to Linux based development and execution? Personally, I haven't done a darn thing with Cocoa nor do I own a single Apple
Second, where is the list of requirements? I know you're not a Systems Engineer but if you're not worried about this stuff getting out there, why not link us to a list of requirements. I know very little about what you need and therefore would have a hard time advising you on who to approach and how to do the job. I know a little bioinformatics (FASTA)
If you do end up approaching a business to help you, research them. Do they have competitors? Is this their bread and butter or a side project? Have they historically contributed to open source? Figure out these answers so you don't have a pitch meeting that they take as an insult.
My work here is dung.
Getting paid for as little work as possible is the real nature of the itch. Recognize it for what it is; if your developers don't have any motivation to write excellent code, they won't. You'll end up with the barest minimum that satisfies your requirements list and any use cases you gave them, and not one iota more.
I say find a few other people who are in your same field who perhaps are more code minded. Get a group together with a common itch, and organize yourselves to do it together. For small niche products, that's pretty much the only way. Anything else will either be prohibitively expensive (hiring top notch developers with a track history to maintain) or result in mediocre results (hiring developers whose interest stops at the paycheck).
I hate printers.
Perhaps so, but if the programmer is aware that his code will be available for future customers to see, that provides a pretty strong incentive not to churn out crapware. This works in most of the rest of the economy, and it's hard to believe on faith, as so many seem to, that it can't work for software. I doubt that all of the programmers hired to work on Apache or MySQL always feel pumped about writing whatever regression test needs doing, but even if they had no personal pride in their work, there would be the external incentive.
that's actually a very good idea. i'm surprised nobody thought to mention this earlier. there are already tons and tons of open source projects out there. there's no need starting a fresh new project when there's already an open source application that fits your needs and is much more mature and already has a development community around it.
if you're willing to pay the developer(s), there are tons of open source projects out there that could use the funding. who knows, maybe one of them is exactly what you're looking for. it's hard for open source projects to reach critical mass when everyone wants to create their own application rather than contribute to an existing project that might fulfill the same objectives.
one of the great advantages of open source is that there is room for both cooperation and competition. even if you don't find a project that fits your needs perfectly, you might be able to fork an existing implementation that you can use as a starting-off point. that reduces the amount of redundancy in the code space. and if you can revived a dead project, then even better.
i think part of what kills off open source applications is a perceived lack of interest, which is partially due to the dispersal of resources over too many redundant projects. luckily, FOSS being what it is, anyone can pick up a dead or inactive project and resume development on it. so before you go off and contract a developer for a brand new open source program, see what's already out there that might fit your needs.
Every good work of software starts by scratching a developer's personal itch.
That's true, but you're not interpreting it broadly enough.
Sure, if he finds a developer who wants this software already, then that's great. But there are other ways to get people personally engaged in a project.
One is to make sure it involves technical challenges the developer finds interesting. E.g., a good Cocoa developer who's wanted to use Core Data but hasn't. Or, assuming that statistics play a part here, a developer who has always wanted to learn about that. That's not enough on its own, but it's a good start.
Next, find ways to get the developer engaged in the domain. A developer with an interest in this kind of science would be great. A lot of good developers started out studying something else, so it's possible he could find somebody with graduate training in his domain.
Third, connect the developer in a personal way to the people who need the software. If this is lab software, then just pay him to spend a week working in the lab with the future users. Have development happen as close as possible to the users. Maybe in the same room, and certainly close enough that they share the same break areas and would naturally go to lunch together.
Fourth, get a good feedback loop going. Show demos every week or two to actual users. As soon as possible, get an alpha version actually in use, and release updates every week or two. Get everybody together weekly over coffee to talk about how it's working. And occasionally get people together over beers to talk about the bigger picture.
Do all these things, and the developer's personal itch is to make something great that satisfies people he has come to care about, people working in a context he understands intuitively.
Tell that to someone who's used BSD.
With BSD I have source code. I have a kernel I control. I have a window system that supports network display of applications natively. All my tools work from the command line, instead of having to do things from often-limiting GUIs. Said tools are also documented, which is a nice change from Mac OS X (where the docs for Apple tools are patchy, and rarely in the form of man pages). I can run BSD on any hardware I want instead of a restricted set of marked-up branded equipment. Oh, and did I mention the use of a sensible file system instead of HFS+ ?
The same goes for Linux.
Of course, I also have far fewer device drivers, far FAR fewer apps in many categories, less support for things like graphics tablets, and all sorts of other things than would be the case under Mac OS X (or Windows).
Argh!
Mac OS X has a POSIX subsystem based on a mixture of BSD and GNU tools, and a kernel that is in large part based on BSD's. Calling it BSD is a disservice to both BSD and Mac OS X.
Under the US Copyright Act of 1976, works made for hire belong to the person who did the hiring. The employer owns the copyright, not the employee.
See http://www.copyright.gov/circs/circ9.html
Of course, the law is complex, so it is best to specify that you get the copyright in the contract, to eliminate any doubt. But in general, when you hire somebody to produce something, you own the copyright.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.