Is that actually a moat? Seems like all model providers managed to scrape the entire textual internet just fine. If video is the next big thing I don’t see why they won’t scrape that too.
Scraping text across the entire internet is orders of magnitudes easier than scraping YouTube. Even ignoring the sheer volume of data (exabytes), you simply will get blocked at an IP and account level before you make a reasonable dent. Even if you controlled the entire IPv4 space I’m not sure you could scrape all of YouTube without getting every single address banned. IPv6 makes address bans harder, true, but then you’re still left with the problem of actually transferring and then storing that much data.
And we're probably already starting to see that, given the semirecent escalations in game of cat and also cat of youtube and the likes of youtube-dl.
Reminds me of Reddit's cracking down on API access after realizing that their data was useful. But I'd expect both youtube to be quicker on the gun knowing about AI data collection, and have more time because of the orders of magnitude greater bandwidth required to scrape video.
Not really. Lots of companies have valuable data they sell and have been in business for decades just fine. It's even better for reddit because it's user generated so they don't even have to do anything. The users who left during the API debacle are not the vast majority of users which are generally casual and do not give a single shit about what happened, much as tech people like to think otherwise.
Again, this is a techie take. Lots of people for example use ChatGPT for personal therapy and guess which subs their training data comes from, r/relationships etc. Those trying to use them for other means are comparatively less frequent.
> Seems like all model providers managed to scrape the entire textual internet just fine
Google, though, has been doing it for literal decades. That could mean that they have something nobody else (except archive.org) has - a history on how the internet/knowledge has evolved.
Free software can still benefit from a stable ABI. If I want to run the software, it's better to download it in a format my CPU can understand, rather than download source, figure out the dependencies, wait for compiling (let's say it's a large project like Firefox or Chromium that takes hours to compile), and so on.
> If I want to run the software, it's better to download it in a format my CPU can understand, rather than download source, figure out the dependencies, wait for compiling (let's say it's a large project like Firefox or Chromium that takes hours to compile), and so on.
If its a choice between downloading a binary that depends on a stable ABI and compiling the source. They way most Linux software gets installed is downloading a binary that has been compiled for your OS version (from repos), and the next most common way of installing is compiling source through a system that figures out the dependencies for you (source based distros and repos).
There are plenty of services that will accept a PDF and turn it into a letter. There's other services that can do the reverse. Those combined means you can interact with entities expecting physical documents without ever having to actually handle physical paper.
It's a year of roaming of bottom-of-the-barrel backhaul, whose speeds and latency could make a 56k modem jealous. It is down to pure luck whether you get a route that works well enough to be usable.
You are always better off buying a local prepaid SIM at your destination airport.
Do you have any more details on this? I always thought that once the PDP context is established (which is based on the phone providing an APN and optional credentials, not the SIM), the "tunneling" (if any - local breakout is a thing apparently) is handled by the network and is completely transparent and invisible to the phone.
Depending on carrier-specific configuration and firmware phones may be configured to prefer NITZ (time transmitted by the cellular network) instead of NTP. That time is probably what’s off and would explain your observation.
It's trivial in terms that it will cost them nothing, because it's very likely there are no changes to the kernel, or nothing of value nor commercially-sensitive anyway.
It's not trivial in terms of big company bureaucracy - this request will have to go through so many levels of red tape that they (correctly) decided not complying to random people's requests is more profitable.
I'm sure if you actually sue them then they will comply right away, because at that point paying for some engineer's time to tar up the source tree and send it to you now becomes cheaper than lawyer time.
But their analysis is correct in that nobody will waste time/money suing to get what is effectively a stock kernel they can get from the official source anyway. Which is why these complaints are also a bit stupid - they're not asking for anything of value or using the GPL to advance software freedom by freeing up some valuable code, they're just wasting both theirs and others' time asking for something they can already download directly.
> because it's very likely there are no changes to the kernel
That is a gratuitous assumption. My experience is, as long as there is the smallest custom hardware, you will have to make some tweaks here and there.
> they're not asking for anything of value or using the GPL to advance software freedom by freeing up some valuable code, they're just wasting both theirs and others' time asking for something they can already download directly.
I'm sorry that the company which is making lots of money by using a copyrighted SW has to "waste" 200 dollars in some bureaucracy, printing and postage. But is the license of the SW they are using, and should abide by it.
> That is a gratuitous assumption. My experience is, as long as there is the smallest custom hardware, you will have to make some tweaks here and there.
How sure are you small tweaks create a derivative work? In your experience.
No the license does not hold! Fair use exists independently of the GPL license.
Using GPL software does not take away your rights under the law. As much as the angry FSF lawyers want you to believe - I can use any GPL software in any way I choose and have the affirmative defense of fair use for every single claim they throw at me.
Whether I lose or not depends on specific factors of my use - and I'm sorry but one comma isn't going to cut it.
Edit: A single comma will lose 100% of the time to a summary judgement via de minimis. That's just an incredible legal theory you have there and not something you should be spreading.
Edit2: The Beastie Boys famously won via de minimis at summary judgement for a 3 note sample. It matters not whether those 3 notes were GPL notes or not. It matters what the law is.
It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source).
Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work, it just means you need to offer more money).
In this case it's a company that believes they can make a "good" package manager they can sell/monetize somehow and so built that "good" package manager. Turns out it's at least good enough that other people now like it too.
This would never work in a FOSS world because the project will be stuck in endless planning as everyone will have an opinion on how it should be done and nothing will actually get done.
Similar story with systemd - all the bitching you hear about it (to this day!) is the stuff that would've happened during its development phase had it been developed as a typical FOSS project and ultimately made it go nowhere - but instead it's one guy that just did what he wanted and shared it with the world, and enough other people liked it and started building upon it.
I don't know what you think "typical Foss projects" are but in my experience they are exactly like your systemd example: one person that does what they want and share it with the world. The rest of your argument doesn't really make any sense with that in mind.
That's no longer as true as it once was. I get the feeling that quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. For better or worse, there's a lot of push to transition popular projects towards being led by committee. Results are mixed (literally: I see both successes and failures), but that doesn't seem to have any effect on the trend.
Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama.
> quite a few people would consider "benevolent dictator for life" an outdated model for open source communities.
I think what most people dislike are rugpulls and when commercial interests override what contributors/users/maintainers are trying to get out of a project.
For example, we use forgejo at my company because it was not clear to us to what extent gitea would play nicely with us if we externalized a hosted version/deployment their open source software (which they somewhat recently formed a company around, and led to forgejo forking it under the GPL). I'm also not a fan of what minio did recently to that effect, and am skeptical but hopeful that seaweedfs is not going to do something similar.
We ourselves are building out a community around our static site generator https://github.com/accretional/statue as FOSS with commercial backing. The difference is that we're open and transparent about it from the beginning, and static site generators/component libraries are probably some of the least painful to fork or take issue with their direction, vs critical infrastructure like distributed systems' storage layer.
Bottom line is, BDFL works when 1. you aren't asking people to bet their business on you staying benevolent 2. you remain benevolent.
> Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama.
You’re not wrong, but those are the projects we’re talking about in this thread. uv has become large enough to enter this realm.
> Bottom line is, BDFL works when 1. you aren't asking people to bet their business on you staying benevolent 2. you remain benevolent.
That second point is doing a lot of heavy lifting. All of the BDFL models depend on that one person remaining aligned, interested, and open to new ideas. A lot of the small projects I’ve worked with have had BDFL models where even simple issues like the BDFL becoming busy or losing interest became the death knell of the project. On the other hand, I can think of a few committee-style projects where everything collapsed under infighting and drama from the committee.
In reality, most people don't really care about a project's "governance model". When it solves a problem well, they will use it. There are loads of weird tiny libraries you don't even know about that rely one the one guy living in some small town in lithuania to spend his saturdays on maintaining.
More projects should push back against calls for "governance" and "steering committees" and such. As you noticed, they paralyze projects. It took JavaScript seven years to get a half-baked version of Python context managers, and Python itself has slowed down markedly.
The seemingly irresistible social pressure to committee-ize development is a paper tiger. It disappears if you stand your ground and state firmly "This is MY project".
It depends on governance, for want of a better word: if a project has a benevolent dictator then that project will likely be more productive than one that requires consensus building.
That's what I'm saying. Benevolent dictator is the rule, not the exception, in FOSS. Which is why GP's argument that private companies good, FOSS bad, makes no sense.
I think OP is directing their ire towards projects with multiple maintainers, thus is more likely to be hamstrung by consensus building and is thus less productive. It does seem like we've been swamped with drama posts about large open-source projects and their governance, notably with Rust itself, linux incorporating Rust, Pebble, etc. It's not hard to imagine this firehose of dev-drama (that's not even about actual code) overshadowing the fact that the overwhelming majority of code ever written has a benevolent dictator model.
The argument isn't about proprietary vs open, but that design by committee, whether that committee be a bunch of open source heads that we like, or by some group that we've been told to other and hate, has limitations that have been exhibited here.
Maybe for a project of a given size and popularity? But BDFL projects might be more likely to be smaller. Projects with a lot of contributors might be more likely to need consensus building, but if they are productive at doing so they can be very productive due to their larger size. This is to say, project structure is not the only indicator of productivity.
> You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work, it just means you need to offer more money).
Money is indeed a great lubricator.
However, it's not black-and-white: office politics is a long standing term for a reason.
Office politics happen when people determine they can get more money by engaging in politics instead of working. This is just an indicator people aren't being paid enough money (since people politicking around is detrimental to the company, it is better off paying them whatever it takes for them not to engage in such behavior). "You get what you pay for" applies yet again.
> In large companies people engage in politics because it becomes necessary to accomplish large things.
At a large company, your job after a certain level depends on your “impact” and “value delivered”. The challenge is getting 20 other teams to work on your priorities and not their priorities. They too need to play to win to keep their job or get that promotion.
For software engineering, “impact” or “value delivered” are pretty much always your job unless you work somewhere really dysfunctional that’s measuring lines of code or some other nonsense. But that does become a lot about politics after some level.
I would not say it’s about getting other people aligned with your priorities instead of theirs but rather finding ways such that your priorities are aligned. There’s always the “your boss says it needs to help me” sort of priority alignment but much better is to find shared priorities. e.g. “We both need X; let’s work together.” “You need Foo which you could more easily achieve by investing your efforts into my platform Bar.”
If you are a fresh grad, you can mostly just chug along with your tickets and churn out code. Your boss (if you have a good boss) will help you make sure the other people work with you.
When you are higher up, that is when you become said good boss, or that boss's boss, the dynamics of the grandfather comment kick in fully.
Agree. A fresh grad is still measured on “impact” but that impact is generally localized. e.g. Quality of individual code and design vs ability to wrangle others to work with you.
Impact is a handwavy way of saying “is your work good for the company”.
Exceeds 1. Politics is the craft of influence. And, debatably, there's a politic even when population size=1, between your subconscious instinctive mind (eat the entire box of donuts) versus your conscious mind (don't spike your blood sugar).
I think too many people happens because a company would rather hire 10 "market rate" people than 3 well-compensated ones. Headcount inflation dilutes responsibility and rewards, so even if one of the "market rate" guys does the best work possible they won't get rewarded proportionally... so if hard work isn't going to get them adequate comp, maybe politics will.
Alternatively, companies hire multiple subject domain experts, and pay them handsomely.
The experts believe they've been hired for the value of their opinions, rather than for being 'yes-people', and have differing opinions to each other.
At a certain pay threshold, there are multiple peoples who's motivation is not "how do I maximise my compensation?" and instead is "how do I do the best work I can?" Sometimes this presents as vocal disagreements between experts.
> a company would rather hire 10 "market rate" people than 3 well-compensated ones
The former is probably easier. They don't have to justify or determine the salaries, and don't have to figure out who's worth the money, and don't have to figure out how to figure that out.
It also comes that the well-compensated people are probably that because they know how to advocate for their worth, which usually includes a list of things they will tolerate and a list they will not, whereas "market rate" is just happy to be there and more inclined to go along with, ya know, whatever.
I believe incompetence is the key. When someone cannot compete (or the office does not use yardstick that can be measurable) politics is the only way to get you up.
Switch to what Nobel prize to man instead of the woman who do the work … sometimes. Take the credit and get the promotion.
It's a question of what you want to invest your time in. Everyone creates output, whether it's lines of code, a smoke screen to hide your social media time, or a set of ongoing conversations and perceptions than you have a use in the organization.
Figuring out how to allocate scarce career resources at a company ("impact", recognition, promotions, etc) is fundamental to the job of getting stuff done in a large organization.
There's an old saying: politics began when two people in a cave found themselves with only one blanket.
Sounds like you’re really down on FOSS and think FOSS projects don’t get stuff done and have no success? You might want to think about that a bit more.
FOSS can sometimes get stuff done but I'd argue it gets stuff done in spite of all the bickering, not because of it. If all the energy spent on arguments or "design by committee" was spent productively FOSS would go much farther (hell maybe we'd finally get that "year of the Linux desktop").
This argument falls apart when you look at Rust and Cargo. uv is literally trying to be "Python's Cargo." The entire blueprint came from a flagship FOSS project.
Rust's development used a structured, community RFC process—endless planning by your definition. The result was a famously well-designed toolchain that the entire community praises. FOSS didn't hold it back; it made it good.
So no, commercial backing isn't the only way to ship something good. FOSS is more than capable to ship great software when done right.
nah, a lot of people working on `uv` have a massive amount of experience working on the rust ecosystem, including `cargo` the rust package manager. `uv` is even advertised as `cargo` for python. And what is `cargo`? a FLOSS project.
Lots of lessons from other FLOSS package managers helped `cargo` become great, and then this knowledge helped shape `uv`.
It doesn't have to make money now. But it's clearly pouring commercial-project-level of resources into uv, on the belief they will somehow recoup that investment later on.
It doesn’t hav eto make money ever on us for it to be worth it to them.
If you’re a Python shop, compare
- writing uv and keeping it private makes package management easier for your own packages
- writing uv and opening it up, and getting all/most third party libs to use it makes package management easier for your own packages and third party packages you use
Keep in mind that "making money" doesn't have to be from people paying to use uv.
It could be that they calculate the existence of uv saves their team more time (and therefore expense) in their other work than it used to create. It could be that recognition for making the tool is worth the cost as a marketing expense. It could be that other companies donate money to them either ahead of time in order to get uv made, or after it was made to encourage more useful tools to be made. etc
«« I don't want to charge people money to use our tools, and I don't want to create an incentive structure whereby our open source offerings are competing with any commercial offerings (which is what you see with a lost of hosted-open-source-SaaS business models).
What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today.
An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]
But the core of what I want to do is this: build great tools, hopefully people like them, hopefully they grow, hopefully companies adopt them; then sell software to those companies that represents the natural next thing they need when building with Python. Hopefully we can build something better than the alternatives by playing well with our OSS, and hopefully we are the natural choice if they're already using our OSS. »»
> This would never work in a FOSS world because the project will be stuck in endless planning as everyone will have an opinion on how it should be done and nothing will actually get done.
numpy is the the de-facto foundation for data science in python, which is one of the main reasons, if not the main reason, why people use python
For knowledge you only use occasionally and always in a context where reference (conventional or AI) is available, why not? That frees up memory/resources to learn more important stuff, the stuff where consulting reference might be too slow or not available.
> if I spend a few years writing some code, you should get to copy it for your own interests
If you publish the code, there's an argument to be made that yes, others should freely use it: if you could (or did) monetize the code yourself you wouldn't publish it. If you didn't, or failed trying to monetize it, maybe it's better for society if everyone else also gets to try?
Right, but what incentives are we really pushing here?
If the only way to make any amount of money or, at least, not be stolen from, is to keep everything internal and be protectionist, then where is the progress?
So much of the modern world is built on open source. Do we really want every company and their mom recreating the world from scratch just so they don't get fucked over? Would things like the iPhone even exist in such a world?
reply