[IronPython] Ironpython 0.7 released!

[Jim Hugunin]

There has been a lot of feedback about the release site we've chosen and
about the license used for this release.  My first comment to everyone
is that I like to get this frank and honest feedback.  I want to build
as large a community as possible around IronPython and it's helpful to
understand where people's concerns lie.  Please bear with me if replies
to some of these questions take longer than replying to technical
questions.  It's not that I'm not reading and thinking about them, but
they can be more difficult to answer.

The feedback on the gotdotnet release site is the simplest.  You're all
basically right and our current setup has some serious flaws.  I knew
this before we made the 0.7 release.  Rather than hold up the IronPython
release to fix these issues with the site first, I thought it would be
better if we got the release out there for people to use and then fixed
the site.  We're working on improving this.  Some people can effectively
work with things as they are and we're getting some valuable feedback
from them.  I hope and expect that we'll get more participation as we
make the site experience better.

The most serious questions are about the license itself.  Many, if not
all, of the license questions would be answered if we were using an
existing OSI approved license.  We certainly considered that option.  At
the end of the day our lawyers were more comfortable with the chosen
license as it had been used in the past for Microsoft source releases.
I agree that the proliferation of licenses is unfortunate; however, this
is something that seems to be inevitable with large companies.  IBM has
at least three different licenses (IPL, CPL and EPL) that they wrote and
decided to use for their OSS projects, so Microsoft isn't unique in
having lawyers who believe that they can draft better licenses than
other lawyers did in the past.

I think that the terms of this license stand up very well on their own.
However, we've clearly invited extra scrutiny by using a new license.
Since I'm not an expert in these areas, I'd like to direct this initial
discussion to Jason Matusow's blog (Swaroop already posted this):
  http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402992.aspx

Let's see how that discussion goes and hopefully we can bring it back to
this list with a better understanding of which issues are real and which
are perceived.

To address some of the specific feedback, I'm going to take Jonathan's
list as a concise version of much of the questions to reply to in the
spirit of the above.

Jonathan LaCour wrote:
> So, to review my pie-in-the-sky wishes to guarantee IronPython
success:
>   1. Switch to a similar, but respected license.
This is a big discussion and I hope you can start it first with Jason
and then bring it back here as mentioned above.

>   2. Ditch the gotdotnet forums.  Make the mailing list "the way".
I'm not going to make the gotdotnet forums disappear overnight because
there is a separate part of the IronPython community that might prefer
those forums to a standard mailing list.  However, I'm not going to make
the mailing list go away either and the community gets to decide where
the interesting discussion takes place.  Right now most of the activity
is here on the mailing list and if people continue to vote this way with
their feet then you'll get your wish.

>   3. Don't require a passport to file bugs.
No passport to file bugs is easy.  We'll send out instructions for how
to do that by the end of the day.  Of course, I suspect that you'd also
like no passport to view the bug database.  This is also good, but will
probably take longer.

>   4. Have a public SVN or CVS repository.
This is an excellent suggestion but again not one that we can implement
overnight.  I know you'd specifically like SVN or CVS, but do you need
those or would any public repository work so long as it had simple
command-line access and was cross-platform?

>   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.

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.

>   6. Have at least one other "committer" (to help lighten the load on
> you).
I do have another committer, Martin Maly, who is working very hard on
the tree.  He is the one who's already fixed most of the reported bugs
and is rapidly growing in his expertise with the source tree.  Martin
also works for Microsoft, directly across the hall from me, so I realize
I don't get any bonus points on this one.  Martin will be the one to
send mail later today about an interim solution for at least filing bugs
without a passport.

Thanks - Jim