[IronPython] Ironpython 0.7 released!

Jim Hugunin jimhug at microsoft.com
Fri Mar 25 03:59:31 CET 2005

Hi Miguel,

Are there any problems that you have with the terms of the IronPython
license, or is it just the lack of the OSI stamp?  I think the terms of
the license are both clear and quite open.  If it's just a matter of the
OSI stamp, I'm not going to be much help there.  You should give this
feedback to Jason Matusow, the director of Shared Source at Microsoft.
Jason has a fairly new blog here http://blogs.msdn.com/jasonmatusow/.
Jason talks a lot on his blog about the notion of "open" as well as
about the extremely wide range of different projects that are released
under the Shared Source umbrella. 

IronPython is going to be run as a very transparent and interactive
project.  I expect to have lots of active discussions with our user
community about different features and about what they're trying to do
with IronPython.  I've been having a great time doing that f2f with
people at PyCon and when I get back from DC I'll want to continue this
process online.  In our first day of release we've already had 6 bugs
filed in the bug database and 5 of them are now marked fixed.  To really
close this loop we also need to make very frequent releases - at a
minimum every 2 weeks and ideally more often.

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.  BTW - I'm also confident that the higher quality and
easier to reproduce bug reports we can get from the community the faster
we'll be able to get to a solid 1.0.

Another place that people should be able to contribute is with building
some of the C-based Python extension modules for IronPython.  I don't
think that we're quite ready for that kind of help just yet, but in a
month or so I'd like to reopen a discussion about how we could structure
that project so that it would work for both the core IronPython
developers and for others in the community who would like to contribute.

I believe that the best software projects are those with a central
architect/benevolent dictator who can drive a consistent vision for the
overall design and implementation of a system.  The only weakness of
this system is that you have to trust that this dictator will remain
both actively working on the project and benevolent.  I could write a
lot of text asking you to trust me that this project will be run that
way; however, I prefer to convince people by actions rather than words.

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.

Thanks - Jim

Miguel de Icaza wrote: 
> Hello,
>     Congratulations on the release of IronPython 0.7, it was a long
> awaited improvement.   There are many outstanding questions on my
>     It is a bit of a shame that the license is stamped as "Shared
> Source" because there are so many licenses labeled as "Shared Source"
> that this will introduce questions that are not necessary.
>     It would also be nice if this was submitted to OSI for approval,
> get a rubber stamp from them in terms of whether IronPython 0.7 will
> possible to redistribute in the future on open source operating
> systems.
>     What will be the process to contribute to IronPython?  Patches to
> get IronPython working out of the box on Mono used to be on this list,
> but they do not seem to be integrated (understandably, it has been a
> long time), but what will be the policy now that IronPython is
> copyrighted by Microsoft?
>     Is this a Microsoft project, that happens to have its source code
> published, or is this is an open source project that happens to be
> and funded by Microsoft?
> Miguel.

More information about the Ironpython-users mailing list