Slashdot Mirror
RFPs And Open Source Projects?
An Anonymous Coward writes: "My company is currently sending out RFPs to various real-time collaboration software vendors. One of the packages we would like to persue is Jabber (the open-source IM/chat software at www.jabber.org). However, for open source projects, where should the RFP be sent? For Jabber, we may use Jabber.com as our reference. But, as my company possibly pursues other open source alternatives, how do we answer this question?"
Well there are two cases to consider.
1) Jabber does all of what you need. In that case just use it.
2) Jabber would need to be modified in some way to meet the needs of the project. In this case you probably want to have someone (Or several someones) working on these improvements full time and one should assume that one way or another you will have to pay them. If you want the Jabber crew to do it Send the RFP to the jabber developer's mailing list. If someone is interested then they will respond. Or just hire a few people to do the work in house. Of course you could just wait and hope that the folks working on jabber add the things you need. But I would recomend proactivly attempting to get them in there by paying somone to write (and *TEST*) the code.
Erlang Developer and podcaster
Maybe you've finally landed on the way that people developing open source projects can be paid. Send an RFP to the group that put the code together and assuming that they'll customize it a bit for you, they could finally make money on the code. This is particularly true for packages that don't have as much commercial power behind them (i.e., when there isn't a project-name.com for them).
I thought others would appreciate a definition, so they wouldn't have to look it up, like I just did.
Taken from Everything2.com:
This is a copy/paste; all typos are property of the author.
It's probably not the best definition, but it answered all I wanted to know.
-Grant/JimTheta
My stupid web site
I'm wondering if the submitter has ever filled out an RFP. Unless it is miraculously tight and succinct, filling out an RFP is one of the most boring, frustrating and inane activities imaginable. The usual RFP has gone through all the departments of a company, which each department adding in their own 2 cents. That usually entails adding poorly worded and contradictory questions that are impossible to answer. Of course, the real gems come from the marketing department, which lists "requirements" along the lines of, "program must be able to think for me, and anticipate what I will want the next day, week, and year."
Bottom line, if you want someone to fill out a typical RFP for free (e.g., open source developer), you are dreaming. If you really want it done, either do it yourself, or hire a consultant to do it.
On the other hand, if you want a shot at something being done by the developers or general users, make a mini-RFP of no more than 10 questions, and see if you can get those answered.
Sometimes it's best to just let stupid people be stupid.
You basically have two choices with respect to adapting open-source software for your purposes:
(1) Take a good look at the credits and people behind an open-source project. Pick out those whom you think are the most involved. Send them RFPs.
(2) Hire programmers, or a consulting company, to modify the source for you. It is OPEN, after all. While people you hire may not be as knowledgable about that project as those who are actively involved in building it, if they're good, they should be able to parse the source and go from there. There is an added benefit in that, if you're only using the software in-house, you'd be able to keep some enhancements proprietary and have an edge over your competitors.
If you're talking about spawning an entirely new open-source project, then it's no different from starting any programming project -- except you'd release the source code, and have some channel where people can send bug reports and patch suggestions.