Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In corporate in-house software development it is common for requirements to be determined through a formal process resulting in the creation of a number of requirements documents. In open source software development, this often seems to be absent. Hence, my question is: how are requirements determined in open source software projects?

By "determining requirements" I simply mean "figuring out what features etc. should be developed as part of a specific software".

share|improve this question
9  
I think it bears pointing out that plenty of Open Source projects have been developed by organizations (companies and academic institutions), rather than loose groups of individual contributors. And as such could have a formal PM/Requirement function. –  MaximR Nov 14 '12 at 2:49
add comment

5 Answers 5

I've been following open source since I first heard about linux in about 1995, and I can't remember ever hearing the word 'requirements' used in that context.

Eric Raymond has a good essay, The Cathedral and the Bazaar, in which he talks about 'scratching your own itch'. If you're trying to solve a problem that you're facing personally, you don't have to refer to requirements documents to figure out if you've solved it or not.

That same essay also talks about listening to your users, which is good advice for everyone, not just open source projects. Open source projects tend to be meritocratic, so 'he who writes the code, makes the rules', more or less.

share|improve this answer
add comment

Open source projects sometimes have intense streams of user feedback, and sometimes corporations would simply pay to make certain features planned and implemented (by hiring their own developers or the original developers).

If your project has 100 users, you probably can develop whatever is most fun to code.

If your project has 100k users, most probably you already have a list of pain points most users want see fixed in the next release, and a list of top N features that users request in your issue tracker and keep asking about on forums.

With this feedback, you can write requirement documents for your core team, create roadmaps to help independent contributors understand your vision, and hope that some of the 100k users will send in patches.

share|improve this answer
add comment

I don't know for sure, but once suggestion is to use an Agile-like methodology, where requirements are raised as tickets (or "cards"), using something like JIRA, with each ticket representing a feature or requirement. Each ticket could then be decomposed into other tickets representing smaller units of work.

As for actually figuring out what an application or piece of software should do, the simple answer is "talking to the other developers." :) "Talking" in this case could mean an e-mail distribution list, forum, or even IRC, anything that allows people in different timezones and geographical locations to chat.

share|improve this answer
add comment

If the problem is a common one like, say, writing a compiler or a browser, the requirements are pretty much given in the form of language standards, target operating systems and target hardware, etc.

For things like GNU Emacs, which is many things to many besides excellently fulfilling its original goal of being a text editor, I think the requirements made sense because of the immense scope to extend it. Chats, emails, newsgroups, code editing, version control come to the mind. There is a research scientist working on Emacspeak. I think similar things can be said of browsers and other things that allow extensions.

If the software is catching up a function that is available only in non open-source software, the requirement is pretty much given again.

EDIT:

When the open source software goes on to maintenance and fewer original requirements remain unmet, most of the requirements can come from bugs, need to adapt to new platforms such as multi core CPUs and other hardware that offer better performance when exploited, and such.

In a fully research based project like the GNU Hurd, I'd think the requirements come from research results and papers.

To sum up,

  • when starting out, the requirements for software that attempts to solve common problems can come from standards documents

  • for software that is catching up to other existing software, the requirements are likely to be to produce all or most of the existing software's feature set and some other features that the developers/users find interesting to have

  • for research projects, papers and other publications could set the requirements

  • when in maintenance, bugs, need to adapt to newer environments can be major source for requirements

share|improve this answer
    
Reading your answer for the first time I could not relate it to the question. But we could say that a kind of problem is a key factor in a way requirements are made. In such a case your answer is promising. Waiting for updates. –  alehro Nov 16 '12 at 18:18
add comment

In corporate in-house software development it is common for requirements to be determined through a formal process resulting in the creation of a number of requirements documents.

Actually, I think that this is more common when doing contract-based development, especially when having an external company doing the development for your company, and there is the legal need for a contract. But lots of other companies control their in-house development in a different way:

  • informal communication

  • prioritized requirements/bugs/issues/tickets lists (honestly, that is not an invention from the "agile" community)

And that's the same way most open source project work - since there is no need for a formal contract, no one bothers to work out big, detailed, formal requirement docs, just small, painless lists of missing features or issues to be solved.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.