[IronPython] IronPython contributions

David Fraser davidf at sjsoft.com
Thu Sep 21 14:49:09 CEST 2006

Hi Martin

Thanks for the links. The most relevant message I found on the list
stating Microsoft's position was
in which Jim Hugunin states:
> That said, we're not going to be accepting any external code
> contributions to the core engine at this time.  One reason not to do
> this is that we want to be careful with the IronPython code to keep the
> IP very clean so that it can be comfortably used both by small projects
> as well as by large commercial projects.  There would be a lot of legal
> work for me to get the right sort of contribution process setup to do
> this carefully enough to make all the lawyers happy here.  I think my
> time could be better spent driving the implementation of IronPython and
> working with the user community to come up with the best set of features
> to solve their problems.
> The best way to contribute to IronPython today is by submitting simple
> easy to reproduce bug reports and well thought out and clearly explained
> feature requests.  Thanks to those of you who've already done that.
> Given the early and rapidly changing state of IronPython, as a developer
> I'd much rather have a clear test case than a patch file for almost any
> bug because I can usually develop the fix myself faster than I can
> understand and validate an externally submitted patch.  Often bugs will
> be in areas under rapid development and the right fix requires
> understanding not just the code where it is, but the model in my head of
> where the code should be going.  Based on my experience with both
> AspectJ and Jython I'm rather confident that at this stage of the
> project external code contributions would slow things down rather than
> speeding them up.
And later on:
> I personally believe that the single best thing about a BSD-style
> license is that it provides the community with the ultimate check on the
> project leadership.  If their concerns and needs aren't being addressed
> then the community can fork the code base and go their own way.  Forks
> are a terrible thing for projects and happen pretty rarely.  Forks are
> also expensive for the community because they now have the whole code
> base to grow and maintain.  Good projects should always be responsive to
> their community of users, and the ability to fork is one way to make
> sure this happens.
The trouble is, now that 1.0 has been reached, a whole bunch of Python
developers are going to want to try out IronPython, find things that
could have improvements, and make contributions.
Surely now it would be worthwhile to set up the necessary process? This
is quite common in the open source/free software world and there are a
few options:
1) Assume any contributions are given under the required license (too
loose, not appropriate)
2) Require sign-off on any contributions as being under the required license
3) Require (usually joint) copyright assignment to the maintainer (and
therefore signoff)
There were several other emails on the list arguing for this (probably
more elegant than me)
Unless this is done, people like Seo and me who have patches have no
choice but to fork... which as Jim says would be unfortunate. Of course
changes could later be incorporated back once the necessary process has
been set up.
In fact in a later posting
Jim said:
> >/   5. Be open to accepting external patches.
> /I'm certainly open to this idea if I could be convinced that the value
> of the patches would be worth the large effort needed to accept them at
> this time.  Given the company that I work for, I would have to spend a
> LOT of time with lawyers working out the right contribution policy in
> order to accept even small patches.  This extreme level of legal caution
> is part of working for a large company.  I don't believe that's the best
> way for me to spend my time right now in order to build the best
> IronPython 1.0.  After 1.0, the value of building a strong external
> developer community goes up and I expect to revisit this question.
Yay, time to revisit it :)
One of the main advantages of an open source license is being able to
accept contributions, I am sure that given the maturing state of the
project this would be a worthwhile thing for IronPython. (And of course,
there have been other projects at Microsoft under such licenses that
have accepted patches - for example WiX, using option 3 above - see
Later in the second posting Jim said:
> As I said in my earlier email, I'd also like to figure out a way to
> encourage contributions in the short-term not to the IronPython core
> engine but in the space of porting CPython extension modules or building
> new IronPython-specific modules.  Technically these are very appealing
> places to accept contributions because each module is a nice modular
> entity.  Needless to say, there are a few other legal and infrastructure
> questions that I'm trying to answer before opening a new topic like this
> one.
I think at the moment Seo's suggestion of a sourceforge project is the
best way to manage this. Mostly I would expect CPython-porting etc to be
done by existing Python developers who would be more comfortable with a
sourceforge site. (Of course, the answers to the above licensing
question would affect this). Seo, are you still planning on doing this?

Hope we can get some progress here


Martin Maly wrote:
> Actually, there were some related discussions after the release of IronPython 0.7. It is archived in the list archives, starting in March 2005. Hopefully, it will answer some of your questions. Second link is Jason Matusow's blog which has some related comments too.
> http://lists.ironpython.com/pipermail/users-ironpython.com/2005-March/date.html
> http://blogs.msdn.com/jasonmatusow/archive/2005/03.aspx
> Martin
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David Fraser
> Sent: Friday, September 15, 2006 10:11 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] socket for IronPython update
> Dino Viehland wrote:
>> Unfortunately we cannot currently accept changes back into the IronPython core right now. :(
> Not at all? What are the issues?
> David
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

More information about the Ironpython-users mailing list