The context is not clear. Is this regarding Conda.jl? On Mon, Nov 2, 2015 at 4:00 PM, <[email protected]> wrote:
> <personal-opinion> > I don't think you should support Anaconda Python. I realize it is > convenient. Providing a sort of private copy of Python and its packages > makes sense. It simplifies installation and maintenance of key Julia > dependencies for users. I just don't think you should use Anaconda to do > it. > > Anaconda is fork of Python, its package management, its primary package > repository, and many of the packages themselves. Forks are BAD. It > borders on a commercial lock-in or, at a minimum, a technical lock-in to > Anaconda. > > I am a commercial software guy by experience. I made a living from > commercial software and find that to be completely honorable. This is not > an anti-commercial rant. It IS, on the other hand, an anti-fork rant. > > Python is a vibrant community. Julia is a vibrant community on a very > nice trajectory. May they both continue. Rather than a philosophical > discussion of Continuum and various open source license types, lets think > about this from the standpoint of Julia. > > Would you like it if someone came along and forked all of Julia, > especially Pkg, and created forks of every package? To do so would be > entirely compliant with the MIT open source license. So, it would be legal > (not that license enforcement is common in the open source world). But, > would it be DESIRABLE? You've done a fine thing to rely largely on git and > github. > > Probably not. Is it possible that someone proposing enhancements found > that their suggestions were rejected? Well, that can happen. Perhaps that > would lead to a fork. But, if there was community endorsement of the > suggestions from some reasonable plurality of members and enhancements > could be made without injury to those preferring some other code path, it > would be reasonable to accommodate particularly if the proposers backed > their suggestions with effort--working code that could be integrated under > the conditions mentioned. I depict this in a somewhat negative way, but my > point is to confirm that *contributing is better than forking*. > > Typically, it is easier--and less negative--than the scenario I depicted. > There is a community. Some leaders are very technically adept and have a > vision (e.g., Julia is not C, Python, R, or Java so it won't do things just > like those or other languages...) so they have some sway over final > inclusion decisions. And these technical leaders do care what the > community suggests; are open to suggestions and contributions; occasionally > reject some input with transparent reasons (transparency may not convince > the proposer, but it is good for everyone to see the dialog and decisions); > and often accept suggestions--implementing the suggestions themselves or > accepting pull requests. But, realistically the core team makes most of > the commits and carries most of the work. > > This is probably how we want it to work. We probably don't want a fork of > Julia and hope to avoid it and we will see Julia grow and be enhanced--most > often on the path and vision of the founders and sometimes with the > contributions of others. In the spirt of "do unto others...", let's not > encourage a fork of Python. > > This would mean using Python releases of the Python Software Foundation > (PSF) and its package repository PyPI. There will be some inconvenience. > Perhaps not all of the Python "cousins" are enamored of Julia and aren't > eager to be helpful. Or perhaps they are merely neutral and busy. But, it > supports their community to endorse it. Do unto others... As a serious > practical matter, the communities are not distinct. Many user-developers > do use both Julia and Python. We'd like both communities to thrive. I > think Continuum would probably concur with the broad sentiment, though not > with my personal opinion about using Anaconda as a Julia dependency. > > This requires some deep thought. Using Anaconda is certainly a near-term > convenience. On Windows, it is possible to get most of the same benefits > from the less commercially oriented release WinPython. On Mac, ...from > Homebrew, which is also quite non-commercial. On Linux, ...well, that is > another kettle of fragmentation--and probably better to rely on PSF than a > bunch of package repositories. Consider: how do you want the Julia > community to develop? How does the Julia community overlap with the Python > community (and to a lesser extent the R community)? How do choices affect > the healthy, long-term evolution of an open source community? > </personal opinion> > > I've left out discussion of how open source communities can attract > commercial participants. That is indeed beneficial. Look to Cloudera's > role in the Hadoop community for a good example of how this can work. >
