some of these problems seem mutualy exclusive
Allocating Research Effort
- Standard social network analysis software is difficult to use, and employs a number of idosyncratic user interface elements. I'm not interested in airing dirty laundry for any particular program, but I'm sure that - in general - we can benefit from taking human interface guidelines and interaction designers (such as the folks at sigCHI very seriously). And ask that software designers pay attention to the subtleties that make life easier for newbies - particularly students - to use the program. Clear documentation is not a substitute for a clear program.
Open Source vs. Proprietary
- If a program is closed source and people have to pay for it, there's almost always someone who will want to write a similar program that is open source and free (Internet Explorer -> Firefox / Photoshop -> GIMP / MS Office -> Open Office). That's happening, and that's a very admirable and democratic reason to reinvent the wheel.
- Also, using Free Software enables others to review the code that generated one's results, or to repeat aspects of the work; is that the gold standard for peer review?
- Closed-source tools have the advantage that the authors don't have to worry about the complications involved in letting other people look at your code (e.g., lots of questions about the hard parts), plus (for those trying to sell their software) you're less likely to lose sales to derived works.
- Open-source tools and libraries can leverage the expertise of everyone that wants to go look at your source code (JUNG has received a great deal of help from its user community), but I suspect tends to be more time-intensive in general.
- software that people use for their analyses is not always either available to others, or documented, so that analytic results can be confirmed.
- Incomplete featuresets. If a closed source program doesn't have the algorithm I want (for example, Mark Newman seems to write interesting algorithms faster than I write emails), I can ask someone to implement it - and they'll get to it when they get the chance. Or if I know what I'm doing, I can implement it in 'my program'. If its open source, I can implement it in their program, but if I don't know the language, I'm still going to implement it in 'my program'.
Platform / OS Compatibility
tools and libraries (mostly tools) out there that only run on one platform: if you use that platform, or can fake it (via emulation or virtualization) then you're fine, but if not, you're out of luck. (This is where this discussion started, of course: some of the most widely used tools are Windows-only.)
Complexity (er, complicated-ness)
- Commercial clients are overwhelmed with many of the SNA metrics -- if they can not grasp it they will not use it. Most clients settle on 3-5 metrics that fit their needs.
there are a few pretty good non-free libraries and tools out there, but most people can't afford them. On the other hand, if you're not selling your software, then you'd better hope that whoever it is that's paying your salary doesn't mind you working on it.
Some libraries are optimized for flexibility; some for usability; some for space performance, some for time performance, etc. It's
hard to serve all of these needs simultaneously, and different packages have different tradeoffs.
Documentation and support