Do open source projects need or want Business Analysts?

October 23, 2008 11:46 AM

This Cnet article got me thinking. I work as a Business Analyst, and as part of my job I do a lot of QA, requirements gathering and refining, user documentation, and other things. Is this a skill set that would be useful to any open source projects? When I've looked in the past, it's seemed like mainly people were looking for coders and testers. It seems like a great way to do some volunteer work and learn new technology and methodologies (different SDLC models, for instance), but I don't know if middle men like me have a place in the open source world.
posted by Lentrohamsanin to Computers & Internet (6 answers total)

User documentation is a huge problem for many open source projects, because it's usually something programmers don't want to spend much time on. Most projects love it when people help out with that. QA is always incredibly useful. I think requirements gathering and refining might be a harder niche, because so many open-source projects are scratching the programmer's itch, so they already have a pretty good idea of what the requirements are. But this could also prove very useful for the kinds of projects that are more end-user- or business- facing, rather than those intended towards technical people. In short, I think there are plenty of projects that would jump at the opportunity to have someone like you work with the project. The one thing to be careful about is that, unlike many business environments, programmers tend to be "in charge" of open source projects and would bristle at a business analyst coming in and telling them what they should be doing. So you'll need to be humble, start small (say, with documentation and testing), and gradually build the trust of the coders before starting to take a more active role in where the project is going.
posted by Emanuel at 12:00 PM on October 23, 2008

Elements of this are desperately needed by a lot of open source projects, but most open source coders aren't aware of it and therefore won't respond to it.

Unless you can also code, getting OS coders to do what they should be doing instead of what they want to do (minesweeper inside a software updater anyone?) is virtually impossible.
posted by bonaldi at 1:08 PM on October 23, 2008

Yes! Yes! Yes!

I think a lot of open source projects are mostly about "scratching an itch" for the developers, and that's why there are so many projects that are so short-lived. The developers, who are mostly coders, don't have the knowledge (or interest) in the business end, to take their software to the next level. Generally, I think, people who are interested in coding aren't as interested in the business aspects.

I'm involved with an open source project, and while I think that our code is great, we really need help with things like documentation, marketing, and those sorts of things. People with "actual" business knowledge would be a great asset.
posted by Morydd at 2:18 PM on October 23, 2008

I'd say Emanuel has it right for small open source projects. I don't know much about how larger projects (the Linux kernel, Apache, Mozilla) are run, though.

I was a developer for K-Meleon (Mozilla-based web browser for Windows) several years back, and there was one guy who was a huge asset to the project without doing any coding. He did pretty much exactly what you're describing, which amounted to a lot of helpful management. He was sort of the unofficial manager of the bug database, the forums, and the documentation. He'd keep an eye on the issues in the forums, answer peoples' questions, bring bug reports into the database from the forums, perform bug triage, keep track of who tested what and what was still untested, generally keep things synchronized, etc. etc. etc.

Emanuel is also right that your approach to any particular project needs to be slow. As a developer, I showed up one day and started working on a piece of the code that I wanted to improve. ... submitted patches, was given access to the CVS repository after the existing developers saw it was good, kept working on what I started and branched out to fix things in other areas as well... Eventually, I was more or less one of the primary developers. I saw other developers come in similarly. You can do the same in your role. Fix up some of the documentation and send it in. Start testing some fixes in the development code and/or organize test reports coming in from other users in a mailing list or forum. Eventually you'll be trusted and have a role in guiding things.

I don't know much about SDLC, and I think most small projects won't either. It's usually one or a few people who want to write a program. So they do. And then they have users so they start dealing with bug reports and feature requests. It's not terribly formalized, and I don't think it usually follows any particular structure. Maybe you could suggest some structure once you're in. Just remember, the motivation and interests of the other participants are much different than in any business.
posted by whatnotever at 2:28 PM on October 23, 2008

THANK you, Lentrohamsanin. I'm primarily a BA as well, read the same article, and had exactly the same reaction as you. I'm very interested in contributing to the open-source environment, but have only dabbled in coding. The suggestions about improving bug tracking, user response, QA and documentation are much appreciated.
posted by sapere aude at 2:43 PM on October 23, 2008

Quality Assurance is one area where a large majority of open source projects are critically lacking. I don't know what sorts of QA a business analyst does, but most projects are lucky to have one or two people triaging and fixing bug reports. This is nice for small projects, but it does require you to be able to catch the attention of people who DO code if you can't. Beyond simply treading water, very few projects have test cases and so on for features. There's perrenial projects to write frameworks, but little results. Dogtail, abbot and junit exist but are underutilized.

What this means for you is both opportunity and a challenge. Projects like Ubuntu Linux have fledgling automated QA projects, but they lack best practices to promote across distros and upstreams. If this is at all something you're interested in, read up on the subject, pick three small projects (the smaller the better!) and introduce yourself to one of them and see if they're interested. The challenge will be getting a project on board for the extra work and seeing it to completion. The opportunity would be having a skill few other open source participants have and having demonstrated results and benefits for projects.

Requirements gathering is a different story -- many developers, both open and closed sort of view it as a dark art of lies. Steve Yegge had a blog post entitled "Business Requirements are Bullshit", in which he declares that requirements gathering is mostly speculative and therefore wrong. There are a few large projects that have grown large enough to be able to do this: Ubuntu Brainstorm and the GIMP UI brainstorm attempt to solicit advice from the people who use the software, a luxury many small and beginning projects don't have, and many don't even want. There's a phrase out there called "patches welcome" occasionally offered to feature suggestions which is basically a clever way of telling the suggester to go fuck off. Or to motivate new software, if the bluff is called ;)

User Documentation is another commonly neglected area, and one I'd advise you to find willing participants for. Ubuntu has a Documentation Project that theoretically looks after the wiki and documentation. The forums are also used as a howto, and I find it a bit offensive that they're used that way -- only the poster has the right to edit the guide, and there becomes two or three junk guides rather than one good, collaborative document.
posted by pwnguin at 3:16 PM on October 23, 2008