ANN: Enthought Python Distribution - Beta
Greetings, Enthought is very excited about our pending wide-release of the Enthought Python Distribution (EPD). After much effort, we finally think we're close to the first non-beta release. As one more quality check, we'd love to impose on you guys one more time to try out a just- minted beta release for Windows (EPD 2.5.2001_beta1) and give us some feedback. Any major problems will, of course, be fixed for the next release, but we're open to any suggestions for improvement for future releases as well. http://www.enthought.com/epd For those of you unfamiliar with EPD, it's a "kitchen-sink-included" distribution of Python with over 60 additional tools and libraries. It's bundled into a nice MSI installer on Windows and includes NumPy, SciPy, IPython, 2D and 3D visualization, database adapters and a lot of other tools right out of the box. We'll have support for RedHat and Mac OS X in a general release very soon. For academic, non-profit or hobbyist use, EPD is, and will remain, free. We are charging an annual subscription for commercial and governmental access to downloads and updates of EPD. Downloaded files may be used indefinitely past the subscription term. You are welcome to try out the beta indefinitely, regardless of your commercial/non- commercial persuasion. When the final (non-beta) version is released, commercial folks can try it for 30 days. You can check out the license terms (http://www.enthought.com/products/epdlicense.php) if you're interested in the details. EPD is compelling because it solves a lingering packaging and distribution problem, but also because of the libraries which it includes. We owe many folks on this list a debt of gratitude for their work on some really great tools. So, thanks ... and enjoy! Best Regards, Travis N. Vaught
What exactly is the relationship between Enthought and the scipy developers and how will it affect future releases of scipy and numpy? Will scipy evolve to the point where the Enthought version is required for all practical purposes? John On Wed, Feb 27, 2008 at 9:13 PM, Travis Vaught <travis@enthought.com> wrote:
Greetings,
Enthought is very excited about our pending wide-release of the Enthought Python Distribution (EPD). After much effort, we finally think we're close to the first non-beta release. As one more quality check, we'd love to impose on you guys one more time to try out a just- minted beta release for Windows (EPD 2.5.2001_beta1) and give us some feedback. Any major problems will, of course, be fixed for the next release, but we're open to any suggestions for improvement for future releases as well.
For those of you unfamiliar with EPD, it's a "kitchen-sink-included" distribution of Python with over 60 additional tools and libraries. It's bundled into a nice MSI installer on Windows and includes NumPy, SciPy, IPython, 2D and 3D visualization, database adapters and a lot of other tools right out of the box. We'll have support for RedHat and Mac OS X in a general release very soon.
For academic, non-profit or hobbyist use, EPD is, and will remain, free. We are charging an annual subscription for commercial and governmental access to downloads and updates of EPD. Downloaded files may be used indefinitely past the subscription term. You are welcome to try out the beta indefinitely, regardless of your commercial/non- commercial persuasion. When the final (non-beta) version is released, commercial folks can try it for 30 days. You can check out the license terms (http://www.enthought.com/products/epdlicense.php) if you're interested in the details.
EPD is compelling because it solves a lingering packaging and distribution problem, but also because of the libraries which it includes. We owe many folks on this list a debt of gratitude for their work on some really great tools. So, thanks ... and enjoy!
Best Regards,
Travis N. Vaught
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
-- John Ollinger University of Wisconsin Waisman Center, T233 1500 Highland Ave Madison, WI 53711 http://brainimaging.waisman.wisc.edu/~jjo/<http://brainimaging.waisman.wisc.edu/%7Ejjo/>
On Wed, Feb 27, 2008 at 10:27 PM, John Ollinger <ollinger@wisc.edu> wrote:
What exactly is the relationship between Enthought and the scipy developers
Enthought employs a few of them, namely Travis Oliphant and myself. Enthought, Travis Oliphant, and Pearu Peterson made the initial contributions that started the scipy project in the first place. Enthought hosts scipy.org. Enthought contributes a fair amount of time and money to numpy and scipy development, still.
and how will it affect future releases of scipy and numpy?
Travis and I will be able to work on them, mostly. What are you worried about happening?
Will scipy evolve to the point where the Enthought version is required for all practical purposes?
No. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
I apologize for the tone of my email - it was the result of late-hours, a migraine, and memories of past bad experiences. I spent 3 years in the 80's writing software for a scanner that was ostensibly developed for use at a university. Then the hardware guys formed a company and eventually made tons of money while the two of us developing software got a one-time shot at some consulting, $2000 in royalties, (which was exactly equal to the university's share,) and lost our jobs. A few years later I inadvertently bought software that I had written during those three years. Hence the paranoia. The combination of open-source software and for-profit companies do raise some legitimate questions, so I don't think that it is entirely unreasonable for people to wonder about this. John On Wed, Feb 27, 2008 at 11:18 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Feb 27, 2008 at 10:27 PM, John Ollinger <ollinger@wisc.edu> wrote:
What exactly is the relationship between Enthought and the scipy developers
Enthought employs a few of them, namely Travis Oliphant and myself. Enthought, Travis Oliphant, and Pearu Peterson made the initial contributions that started the scipy project in the first place. Enthought hosts scipy.org. Enthought contributes a fair amount of time and money to numpy and scipy development, still.
and how will it affect future releases of scipy and numpy?
Travis and I will be able to work on them, mostly. What are you worried about happening?
Will scipy evolve to the point where the Enthought version is required for all practical purposes?
No.
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
-- John Ollinger University of Wisconsin Waisman Center, T233 1500 Highland Ave Madison, WI 53711 http://brainimaging.waisman.wisc.edu/~jjo/
On Thu, Feb 28, 2008 at 12:21 PM, John Ollinger <ollinger@wisc.edu> wrote:
I apologize for the tone of my email - it was the result of late-hours, a migraine, and memories of past bad experiences. I spent 3 years in the 80's writing software for a scanner that was ostensibly developed for use at a university. Then the hardware guys formed a company and eventually made tons of money while the two of us developing software got a one-time shot at some consulting, $2000 in royalties, (which was exactly equal to the university's share,) and lost our jobs. A few years later I inadvertently bought software that I had written during those three years. Hence the paranoia.
The combination of open-source software and for-profit companies do raise some legitimate questions, so I don't think that it is entirely unreasonable for people to wonder about this.
Fair enough. However, I think that our history of support for a free and open scipy since (quite literally) the beginning should speak for itself. Nothing has changed in that regard. scipy would be much less useful to us were we to attempt to close it up, not that we could succeed. A big difference between your situation (as far as I can tell) and scipy's is that scipy's code is authentically open source and freely available on the Internet. Even if we were to shut down scipy.org and "take our ball and go home," there are any number of people with the source already who can simply start up again on code.google.com. We would inconvenience the community, but we couldn't stop it from developing scipy in any way. But all of that would be incredibly stupid of us. Our support of scipy has been one of the most substantial advertisements for our consulting services. For a long time, it was our *only* advertisement. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Hi,
But all of that would be incredibly stupid of us. Our support of scipy has been one of the most substantial advertisements for our consulting services. For a long time, it was our *only* advertisement.
All good reasonable points. I guess the call here is whether charging companies and government institutions for the bundle will have a small enough deterrent effect on those trying out scientific python to be an insignificant barrier to its uptake, Matthew
On Thu, Feb 28, 2008 at 2:03 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
But all of that would be incredibly stupid of us. Our support of scipy has been one of the most substantial advertisements for our consulting services. For a long time, it was our *only* advertisement.
All good reasonable points. I guess the call here is whether charging companies and government institutions for the bundle will have a small enough deterrent effect on those trying out scientific python to be an insignificant barrier to its uptake,
To the contrary, we've found that it reduces the hesitation of these institutions to adopt Python substantially. IT departments *hate* deploying dozens of random things from various internet sources with no support. We are providing an *additional* service to what is currently available. It's not like we're reducing what is currently freely available. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Hi,
All good reasonable points. I guess the call here is whether charging companies and government institutions for the bundle will have a small enough deterrent effect on those trying out scientific python to be an insignificant barrier to its uptake,
To the contrary, we've found that it reduces the hesitation of these institutions to adopt Python substantially. IT departments *hate* deploying dozens of random things from various internet sources with no support.
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say. Matthew
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users. Matthew
On Thu, Feb 28, 2008 at 2:27 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users.
Without EPD, they only have the latter alternative, so I'm not really sure how the presence of EPD can harm anything. Let me be clear on one thing which people may be fearing: we will not stop making separate, freely available binary releases of numpy and scipy. Nor will we stop anyone else from making such binaries. We are interested in making money by *adding* services, not holding them hostage. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Without EPD, they only have the latter alternative, so I'm not really sure how the presence of EPD can harm anything.
I'm not suggesting EPD is a bad idea, it is a very good idea, I'm just saying, that charging for it may reduce the tendency for people to try it, and therefore try python / numpy, compared to the option of making it free. Matthew
I absolutely agree with that. Business are very suspicious of software that they don't have specific rights to. If money changes hands, an implied contract exists even if no explicit contract is executed. It is also much easier for an IT manager to justify a low-cost option than a no-cost option because it is not in the nature of business executives to trust something that is free. In fact, the $2000 I mentioned in my email above was forced on the programmers. This occurred two years after we left the university, and we knew the university would take the money anyway, so we tried to give the rights to the company for free. They insisted on selling, so I suggested a price of $1, but they said that wasn't enough. So I said $2000 and that is what they paid the university. John On Thu, Feb 28, 2008 at 2:36 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Thu, Feb 28, 2008 at 2:27 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users.
Without EPD, they only have the latter alternative, so I'm not really sure how the presence of EPD can harm anything.
Let me be clear on one thing which people may be fearing: we will not stop making separate, freely available binary releases of numpy and scipy. Nor will we stop anyone else from making such binaries.
We are interested in making money by *adding* services, not holding them hostage.
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
-- John Ollinger University of Wisconsin Waisman Center, T233 1500 Highland Ave Madison, WI 53711 http://brainimaging.waisman.wisc.edu/~jjo/
That is indeed a valid scenario. On my Linux engineering systems we just built everything from scratch but on our institutional PC systems we like to have an MSI ready to go and I have gone so far as to establish the EPD (prior version) as our company standard python installation for those Windows users who need it. Of course now that decision puts us in a bind as we will in the future need to establish a contract with Enthought before continuing with this standard. (Of course I would have had this same situation had I selected the ActiveState version...) As this being a big deal? No, not really; just an annoyance. Governments and companies know how to license software and indeed prefer the warm fussy of paid support to the FOSS model. People may just fall back to the python.org installer and never know the joy of the Enthought tool suite and scipy/numpy. I don't know how often that may happen however. -Robin Friedrich -----Original Message----- From: scipy-dev-bounces@scipy.org [mailto:scipy-dev-bounces@scipy.org] On Behalf Of Matthew Brett Sent: Thursday, February 28, 2008 2:28 PM To: SciPy Developers List Subject: Re: [SciPy-dev] ANN: Enthought Python Distribution - Beta
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users. Matthew _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
That is indeed a valid scenario. On my Linux engineering systems we just built everything from scratch but on our institutional PC systems we like to have an MSI ready to go and I have gone so far as to establish the EPD (prior version) as our company standard python installation for those Windows users who need it. Of course now that decision puts us in a bind as we will in the future need to establish a contract with Enthought before continuing with this standard. Remember that you can download EPD without paying anything and feel
Friedrich, Robin K wrote: perfectly fine about it if you are just trying out the software and have not decided to use it in your work. Once you decide to make serious use of Python (assuming you will want multiple packages), and want the help maintaining binaries, you can manage this in many ways: 1) A site-wide yearly subscription that would let you install it on as many machines as you like 2) Purchasing individual subscriptions for the users that do rely on it. We are really hoping that EPD will help more people than it hurts and trying to make the terms as agreeable as possible (while still enabling us to produce EPD). Best regards, -Travis Oliphant Enthought, Inc.
Understood. Yes this all sounds very reasonable. Might I inquire about the availability of the Mac 10.5 EPD bundle? Will it be available prior to PyCon. I want to configure my MacBook with it. Installing from scratch is not working right now due to VTK and VTK isn't building from source for me on Leopard. Thanks, Robin -----Original Message----- From: scipy-dev-bounces@scipy.org [mailto:scipy-dev-bounces@scipy.org] On Behalf Of Travis E. Oliphant Sent: Friday, February 29, 2008 1:03 AM To: SciPy Developers List Subject: Re: [SciPy-dev] ANN: Enthought Python Distribution - Beta Remember that you can download EPD without paying anything and feel perfectly fine about it if you are just trying out the software and have not decided to use it in your work. Once you decide to make serious use of Python (assuming you will want multiple packages), and want the help maintaining binaries, you can manage this in many ways: 1) A site-wide yearly subscription that would let you install it on as many machines as you like 2) Purchasing individual subscriptions for the users that do rely on it. We are really hoping that EPD will help more people than it hurts and trying to make the terms as agreeable as possible (while still enabling us to produce EPD). Best regards, -Travis Oliphant Enthought, Inc. _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Hey Robin, On Feb 29, 2008, at 1:52 PM, Friedrich, Robin K wrote:
Understood. Yes this all sounds very reasonable. Might I inquire about the availability of the Mac 10.5 EPD bundle? Will it be available prior to PyCon.
Actually a pre-PyCon release of the Mac OS X version was a 'stretch goal' for us. It depends a bit on how quickly the RedHat version goes (we're very close!) and how much more work the 'unknown unknowns' are on the Mac. Travis
Matthew Brett wrote:
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users.
We try to advertise and make very clear that there is no charge at all even for commercial users to just try EPD. That same moderately junior person could get EPD from the internet, install it and show all their friends. The only thing we ask is that if a company starts making substantial use of EPD, they help defer the costs of producing it. We are really very keen on having as many people as possible use the tools. We have had requests for a supported binary installation for a long time. So, we are responding. Best regards, -Travis O.
Oh man this is good for me. I have had real problems convincing some users to try python because it is 'free'. Having a support version that I can let them use that is compatible with my open source version, is a life saver. Does it allow for f2py to compile without setting up the compilers myself in windows. I often use this to make callback functions, and it will help make me convince some people. Gabriel On Fri, Feb 29, 2008 at 12:49:38AM -0600, Travis E. Oliphant wrote:
Matthew Brett wrote:
With the bundle - yes of course. I mean, if the bundle becomes the defacto standard for deploying python, numpy etc, and the charges worry people, then they may be less likely to try it. I've no idea whether that will be a big factor - I guess it's difficult to say.
For example - imagine the following scenario. Someone moderately junior has just joined a company or government institution. They become keen on python, start playing with python, VTK and so on, and try and persuade others in the company to try it. If they find they have to ask the accounts people for money before they install the bundle, or they have to build it all from scratch, they may not, which means lost users.
We try to advertise and make very clear that there is no charge at all even for commercial users to just try EPD. That same moderately junior person could get EPD from the internet, install it and show all their friends.
The only thing we ask is that if a company starts making substantial use of EPD, they help defer the costs of producing it. We are really very keen on having as many people as possible use the tools.
We have had requests for a supported binary installation for a long time. So, we are responding.
Best regards,
-Travis O.
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
On Sat, Mar 1, 2008 at 1:17 PM, Gabriel Gellner <ggellner@uoguelph.ca> wrote:
Oh man this is good for me. I have had real problems convincing some users to try python because it is 'free'. Having a support version that I can let them use that is compatible with my open source version, is a life saver.
Does it allow for f2py to compile without setting up the compilers myself in windows. I often use this to make callback functions, and it will help make me convince some people.
g77 is provided along with mingw. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Thu, 28 Feb 2008, Matthew Brett apparently wrote:
I guess the call here is whether charging companies and government institutions for the bundle will have a small enough deterrent effect on those trying out scientific python to be an insignificant barrier to its uptake,
In quite a few cases, this will probably *increase* interest. It's an odd world... But the most important things to stimulate interest from government and large business is an established reputation and the availability of paid support. Cheers, Alan Isaac
But the most important things to stimulate interest from government and large business is an established reputation and the availability of paid support.
Yes, hence the Redhat / Fedora model, as compared to the original Suse model. But if Suse had been the only Linux distribution, and a first timer had to install Suse linux from source, Linux would not be popular. I imagine that's why Suse went for the Redhat / Fedora model in the end. It seems to me that paid support is huge bonus and an active encouragement for those who want it, but having to pay for the original download before assessing it would be a deterrent. Matthew
participants (8)
-
Alan G Isaac -
Friedrich, Robin K -
Gabriel Gellner -
John Ollinger -
Matthew Brett -
Robert Kern -
Travis E. Oliphant -
Travis Vaught