6 ms·

I've been burned too many times by embracing open source products like this. We've been fed promises like these before. They will inevitably get acquired. Year

• deleted 1y ago
  [deleted]
• woodruffw 1y ago
  For what it's worth, I understand this concern. However, I want to emphasize that pyx is intentionally distinct from Astral's tools. From the announcement post: > Beyond the product itself, pyx is also an instantiation of our strategy: our tools remain free, open source, and permissively licensed — forever. Nothing changes there. Instead, we'll offer paid, hosted services that represent the "natural next thing you need" when you're already using our tools: the Astral platform. Basically, we're hoping to address this concern by building a separate sustainable commercial product rather than monetizing our open source tools.
  • pbowyer 1y ago
    This is the way it's worked for PHP's composer packages, and it's worked well.
  • o11c 1y ago
    The entire reason people choose "permissive licenses" is so that it won't last forever. At best, the community can fork the old version without any future features. Only viral licenses are forever.
    • woodruffw 1y ago
      I don't think this is true -- a license's virality doesn't mean that its copyright holders can't switch a future version to a proprietary license; past grants don't imply grants to future work under any open source license.
      • notpushkin 1y ago
        Correct; however, without a CLA and assuming there are outside contributors, relicensing the existing code would be mildly painful, if not downright impossible.
        • woodruffw 1y ago
          You're saying that would be more painful in a viral license setting, right? If so I agree, although I think there's a pretty long track record of financially incentivized companies being willing to take that pain. MongoDB's AGPL transition comes to mind. But, to refocus on the case at hand: Astral's tools don't require contributors to sign a CLA. I understand (and am sympathetic) to the suspicion here, but the bigger picture here is that Astral wants to build services as a product, rather than compromising the open source nature of its tools. That's why the announcement tries to cleanly differentiate between the two.
          • stackskipton 1y ago
            They have no need to, current repos show everything is under MIT/Apache. They could close the source at any time and not worry about CLA. >bigger picture here is that Astral wants to build services as a product What services? pyx? Looks nice but I doubt my boss is going to pay for it. More likely they just say "Whatever, package is in PyPi, use that." UV, Ruff, Ty. Again, maybe they can get some data/quant firm who REALLY cares about speed to use their products. Everyone else will emit a long sigh, grab pip/poetry, black and mypy and move on.
            • pepoluan 1y ago
              It ultimately depends on a company's risk appetite. Some companies specify that packages need to be hosted on their internal repository/artifactory, and for these companies, pyx might be a good tool.
              • jamespo 1y ago
    • krupan 1y ago
      I think you are making a good point, but please don't use the old Steve Baller FUD term, "viral." Copyleft is a better term
      • Muromec 1y ago
        The word "left" is now very charged too, maybe even more than "viral".
        • HiPhish 1y ago
          Every word is charged now, so you might as well use it. "Copyleft" is a fine pun on "copyright".
          • neutronicus 1y ago
            Careful, or you'll get the copyleftists calling you a neo-libre-al.
            • knowitnone2 1y ago
              they call everybody a nazi so by definition, they like living in a nazi country
      • ameliaquining 1y ago
        I don't think the connotation these days is particular negative, in the sense it's being used here. See, e.g., "viral video".
      • codethief 1y ago
        Politics aside, "copyleft" originates from a pun and is hardly self-explanatory, whereas "viral" is.
    • actinium226 1y ago
      By viral, do you mean licenses like GPL that force those who have modified the code to release their changes (if they're distributing binaries that include those changes)? Because FWIW CPython is not GPL. They have their own license but do not require modifications to be made public.
    • thayne 1y ago
      Or they want to get more people to use it.
    • bigstrat2003 1y ago
      This is just plain false and honestly close-minded. People choose permissive licenses for all sorts of reasons. Some might want to close it off later, but lots of people prefer the non-viral nature of permissive licenses, because it doesn't constrain others' license choice in the future. Still others think that permissive licenses are more free than copyleft, and choose them for that reason. Please don't just accuse vast groups of people of being bad-faith actors just because you disagree with their license choice.
  • zemo 1y ago
    > Basically, we're hoping to address this concern by building a separate sustainable commercial product rather than monetizing our open source tools. jfrog artifactory suddenly very scared for its safety
    • mcdow 1y ago
      Only a matter of time before someone makes something better than Artifactory. It’s a low bar to hit imho.
    • cyberax 1y ago
      They've been the only game in town for a while, and their pricing reflects it. But this project is only for Python (for now?) so JFrog is not _immediately_ in danger.
  • zahlman 1y ago
    Will pyx describe a server protocol that could be implemented by others, or otherwise provide software that others can use to host their own servers? (Or maybe even that PyPI can use to improve its own offering?) That is, when using "paid, hosted services like pyx", is one paying for the ability to use the pyx software in and of itself, or is one simply paying for access to Astral's particular server that runs it?
    • woodruffw 1y ago
      I might not be following: what would that protocol entail? pyx uses the same PEP 503/691 interfaces as every other Python index, but those interfaces would likely not be immediately useful to PyPI itself (since it already has them). > or is one simply paying for access to Astral's particular server that runs it? pyx is currently a service being offered by Astral. So it's not something you can currently self-host, if that's what you mean.
      • zahlman 1y ago
        > pyx uses the same PEP 503/691 interfaces as every other Python index ... Then how can it make decisions about how to serve the package request that PyPI can't? Is there not some extension to the protocol so that uv can tell it more about the client system?
        • woodruffw 1y ago
          The repository API allows server-driven content negotiation[1], so pyx can service specialized requests while also honoring the normal 503/691 ones. [1]: https://packaging.python.org/en/latest/specifications/simple-repository-api/#version-format-selection https://packaging.python.org/en/latest/specifications/simple...
          • happymellon 1y ago
            Ah. > honoring the normal 503/691 ones. Embrace > pyx can service specialized requests Extend ... ;)
  • abdullahkhalids 1y ago
    I believe that you are sincere and truthful in what you say. Unfortunately, the integrity of employees is no guard against the greed of investors. Maybe next year investors change the CEO and entire management and they start monetizing the open source tools. There is no way of knowing. But history tells us that there is a non-trivial chance of this happening.
    • dandellion 1y ago
      Yes, at every company I have been with investors, sooner or later they make the calls, what the founders wanted never has much weight a few years in.
    • adr1an 1y ago
      A week later a fork appears and everyone is happy (except those investors, CEO, and management, but it never was about their happiness so...)
  • BrenBarn 1y ago
    It makes sense, but the danger can come when non-paying users unwittingly become dependent on a service that is subsidized by paying customers. What you're describing could make sense if pyx is only private, but what if there is some kind of free-to-use pyx server that people start using? They may not realize they're building on sand until the VC investors start tightening the screws and insist you stop wasting money by providing the free service. (Even with an entirely private setup, there is the risk that it will encourage too much developer attention to shift to working within that silo and thus starve the non-paying community of support, although I think this risk is less, given Python's enormous breadth of usage across communities of various levels of monetization.)
  • physicsguy 1y ago
    Conda said all this as well, and solved the same issues you’re trying to - namely precompiled versions of difficult to build packages. It then went commercial. In the HPC space there are already Easybuild and Spack which make all the compiler tool chain and C and Fortran library dependency stuff very easy. They just haven’t taken off outside as they aim to solve cluster management problems but Spack is easy to self serve.
    • igortg 1y ago
      Yes, it went commercial. But Conda is still free. And the community had built conda-forge to maintain packages. Conda + conda-forge can completly replace Anaconda for most people. So even though they went commercial, they left pretty good things behind for the Open source community.
  • wrasee 1y ago
    The uncertainly over a future rug pull is always real, but in reality I wonder if the actual reason for people's hesitancy is more than just that. In reality I suspect it's closer to one of simply identity and the ownership model itself. Just the very idea that core tooling you depend on is in the hands of a commercial company is enough to many back off in a way one might not be when the tooling is in the hands of a broader community that one can support on more equal terms. @woodruffw I love your quote above that commits you to your open source base and I'm rooting for you. But how about an approach that commits you to this sentence in a more rigorous and legal way, and spin off your open source tooling to a separate community-based entity? Of course, upon that you can continue to maintain sufficient representation to make Astral's commercial products the natural progression and otherwise the model remains the same. That would be a significant transfer of control, but it is that very transfer that would get a overwhelming response from the community and could really unblock these great tools for massive growth. I work a lot with LLVM/Clang and whilst i know Apple and Google are significant contributors I feel confident that LLVM itself exists outside of that yet accept that e.g. Apple's contributions afford them weight to steer the project in ways that match their interests in e.g. Swift and Apple tooling.
  • threatofrain 1y ago
    The hosting and administration part is what’s expensive and can’t be free and open source except when someone pays for it. So is npm open source? Whether it is or isn't doesn't matter as much as whether Microsoft continues to pay the bill.
  • dataflow 1y ago
    I think the only way you can alleviate people's concerns here is by legally binding the company in a way that would adequately address those concerns. Which I don't recall ever seeing any company attempt in such a scenario, probably because it obviously devalues the company as it restricts what a potential future buyer could do with it. Which is exactly why some people don't buy such pinky promises.
• ActorNightly 1y ago
  I agree. If any of the stuff was worthwhile to pursue, it would be merged into pip.
  • woodruffw 1y ago
    This doesn't generalize: you could have said the same thing about pip versus easy_install, but pip clearly has worthwhile improvements over easy_install that were never merged back into the latter.
  • zahlman 1y ago
    Pyx represents the server side, not the client side. The analogue in the pre-existing Python world is PyPI. Many ideas are being added to recent versions of pip that are at least inspired by what uv has done — and many things are possible in uv specifically because of community-wide standards development that also benefits pip. However, pip has some really gnarly internal infrastructure that prevents it from taking advantage of a lot of uv's good ideas (which in turn are not all original). That has a lot to do with why I'm making PAPER. For just one example: uv can quickly install previously installed packages by hard-linking a bunch of files from the cache. For pip to follow suit, it would have to completely redo its caching strategy from the ground up, because right now its cache is designed to save only download effort and not anything else about the installation process. It remembers entire wheels, but finding them in that cache requires knowing the URL from which they were downloaded. Because PyPI organizes the packages in its own database with its own custom URL scheme, pip would have to reach out to PyPI across the Internet in order to figure out where it put its own downloads!
    • notatallshaw 1y ago
      > However, pip has some really gnarly internal infrastructure that prevents it from taking advantage of a lot of uv's good ideas (which in turn are not all original). FWIW, as a pip maintainer, I don't strongly agree with this statement, I think if pip had the same full time employee resources that uv has enjoyed over the last year that a lot of these issues could be solved. I'm not saying here that pip doesn't have some gnarly internal details, just that the bigger thing holding it back is the lack of maintainer resources. > For just one example: uv can quickly install previously installed packages by hard-linking a bunch of files from the cache. For pip to follow suit, it would have to completely redo its caching strategy from the ground up, because right now its cache is designed to save only download effort and not anything else about the installation process. I actually think this isn't a great example, evidenced by the lack of a download or wheel command from uv due to those features not aligning with uv's caching strategy. That said, I do think there are other good examples to your point, like uv's ability to prefetch package metadata, I don't think we're going to be able to implement that in pip any time soon due to probably the need for a complete overhaul of the resolver.
• mnazzaro 1y ago
  This is a valid concern, but astral just has an amazing track record. I was surprised to see the community here on HN responding so cautiously. Been developing in python for about a decade now- whenever astral does something I get excited!
  • halfcat 1y ago
    > This is a valid concern, but astral just has an amazing track record. The issue is, track record is not relevant when the next investors take over.
    • IshKebab 1y ago
      I agree in principle, but in this case uv is open source and SO MUCH better than pip it would be insane not to use it on those grounds. With uv the worst case is it goes closed source in a few years and we all switch to a fork. With pip the best case is that maybe in 10 years they have improved it to fix all the issues that uv has already fixed, and you only spend 10 years using shitty software and putting up with endless bugs and paper cuts.
  • unmole 1y ago
    HN comments default to cynisim.
  • JimDabell 1y ago
    Frankly, it’s weird. You can find this business model all over the open-source world but for some reason Astral in particular is singled out for way more criticism on this than anything else I’ve seen, despite being unambiguously great contributors who have never put a foot wrong as far as I can tell. Microsoft – who invented embrace, extend, and extinguish – own NPM, but I don’t see people wringing their hands over them in every thread that mentions NPM. But you mention Astral here or on Reddit and people line up to tell you it’s only a matter of time before they fuck people over. Why the disparity?
    • aragilar 1y ago
• nerdponx 1y ago
  Has that ever happened in the Python ecosystem specifically? It seems like there would be a community fork led by a couple of medium-size tech companies within days of something like that happening, and all users except the most enterprise-brained would switch.
• sevensor 1y ago
  It’s great that astral are doing what they do, but it’s important to hedge against their success. We must maintain ecosystem fragmentation, or Astral becomes a choke point where a bad actor can seize the entire Python community and extract rent from it. Like Anaconda but successful. So keep using pylint, keep using mypy, keep using PyPI. Not exclusively, but as a deterrent against this kind of capture.
• crystal_revenge 1y ago
  I love using uv, but having worked for a VC funded open source startup, your concerns are spot on. As soon as there is a commercial interest competing with the open source project at the same company the OSS version will begin to degrade, and often the OSS community will be left in the dark about this. The startup I was at had plenty of funding, far too many engineers, and still removed basically every internal resource from the oss project except one person and drove out everyone working on the community end of things. I would also recommend avoiding working for any open source startup if your goal is to get paid to contribute to a community project. Plenty of devs will take a reduced salary to work on a great community project, but most of the engineers I saw definitely got the "bait and switch" and moved immediately to commercial projects.