Contributing to NodeXL (Open Source)

Jul 1, 2009 at 7:59 PM

I'm interested in contributing to the NodeXL project and I'm wondering if you are accepting outside contributions.  If so, how does that happen, and if not....would you be open to that possibility?  There are a couple of barriers as of now, however, they don't seem to be anything insurmountable.

1) The source code available here on CodePlex is a sync from another repository and not the repository that is being used for development.  In order to have NodeXL be a truly open source project we'd need more frequent releases so that outside patches could be tested against the latest code.  Ideally, the NodeXL team would use a repository that's publicly accessible (Github!)

2) Presumably we'd need to construct some contributor guidelines to ensure the patches submitted meet the conventions used in the NodeXL code.

3) A forum for proposing open source contributions would be valuable so that folks who would like to add support for a feature could see if it was something that the rest of the community thinks would be beneficial to add.

I'm sure there are many other issues, however, this thread is just meant to gauge whether outside contributions are possible, and if not how they could be in the future.


~ Steve


Jul 1, 2009 at 8:58 PM

Hello Steve -

I appreciate your offer to contribute to the code in the NodeXL project!

You will be pleased to know that label enhancements you request have recently been scheduled and will release by end of July.

We are also prioritizing improved centrality score performance improvements.  That will also ship in the coming weeks.

The web interface work item remains pending - we are eager to get to it but plan other features which meet our core educational user scenario goals more closely. 

For example, we will support import/export of the UCINet file format, a feature much in demand in the educational context we are targeting.  Other work items coming soon include axes for the X/Y layout option that should make our charts more ready for publication. (We just released an export to XPS format that should make getting NodeXL charts out to pdf more practical).

Your request for a more frequent update to the source code is understandable, we will try to do this more regularly (and recently did update).

We do have some concerns with 3rd party contribution to the main distribution of the NodeXL project based on potential infringement claims on code we did not write ourselves.  Our policy (imposed by understandable legal constraints from our main funder) is to allow for forked versions of the code.  We could accept psuedocoded features that we may be able to implement ourselves for inclusion in the main project fork.  Perhaps you would like to form a NodeXL++ project that builds on our core?

You are among several people who have recently asked for a web UI for NodeXL.  I suggest that a group of you could connect to implement this feature.  I will send an email separately that points you to the others who have enquired.


Marc Smith
(for Team NodeXL)

Jul 3, 2009 at 5:32 PM

I wonder if we might try to bring in some others from MS who have gone through similar steps to make their projects open source and allow contributions.  John Lam of the IronRuby project comes to mind.  Would it be worthwhile for me to drop him an email to see if he has any perspective and advice?  Or at this point is it completely unrealistic to think that NodeXL could become an "open source" project that accepts contributions?

My primary concern with a branch is that in order to support some of the features I'd like to add there may be some significant changes necessary, that would make merging in future changes by the core NodeXL team difficult.  Since it doesn't sound like any outside contribution would make its way into NodeXL directly the maintenance of a "fork" could become a major undertaking which I doubt would be a sustainable proposition.

I'd welcome future dialog on this topic! :)


Jul 3, 2009 at 6:30 PM
Edited Jul 3, 2009 at 8:46 PM

I understand the difficulties of merging, but it might not be as hard as you think.  The vast bulk of the work I've done in the past year (and the work I'll be doing in the coming months) is at the top-level application layer.  I've made few changes in the lower-level class libraries, which have been relatively stable for some time.

On the duplicate edge feature you are interested in adding, I would not want that in the graph-drawing code, at least for now.  Why not?  Because it would complicate the code, and I've opted for simplicity over the let's-provide-all-sorts-of-options approach.  In fact, an early implementation took the latter route: it had a pluggable architecture that allowed custom vertex and edge drawers to be used.  A nice concept, but it proved to be bloated, unwieldy, and nearly impossible to test reliably.  So the current implementation greatly simplifies things with fixed drawing classes, and those who need something more are encouraged to take a copy of the source code (cost: $0) and make whatever changes they feel are necessary.

This may not be the ideal situation for you, but as Marc noted, we have constraints that we must work under.