SDL Moves to GitHub
discourse.libsdl.org
discourse.libsdl.org
This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.
To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days.
This is also why I like sourcehut, it represents to me sort of downshifting movement in the world that seems to be so very overspeeding. But I do feel that sr.ht does need certain almost monkish attitude to be satisfied with the austere facilities.
Making the lives of developers of free software easier has rarely if ever been on the list of priorities for many of the core projects.
I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only muster a small fraction of the engineering hours that a mid-sized for-profit software company could.
In addition, good user-facing software requires more than just good engineering - you need good UX, product direction, etc. Sometimes the creator or maintainer of an OSS program will have the good fortune to be reasonably good at all of these, but it’s very rare, and there aren’t nearly as many UX designers or product managers looking to contribute to open source as there are developers. Even if someone did want to help in this role, the developers on most projects would probably ignore them.
This is the lion's share of the problem, I suspect. OSS projects are driven by the people who write the code, and they don't take orders, and they don't massively value making things easy to use - or even necessarily have much connection with what that means. Current computing is such a pain in the ass that we've basically selected for inhuman levels of persistence and patience, and placed a large cultural value on those traits to boot. "Read the docs", we say. "Use the source", we say.
We don't have any idea how many human factors experts are out there, willing to help, because there's no process for them to contribute beyond "submit a pull request" - and even then, a purely UI tweak will meet with huge resistance. The UI expert is going to have to be a diplomat as well.
Bad UX is subjective. Money doesn't change that.
Suppose we want to optimize user productivity. For any given UX, some users will feel they're more productive with it, and some less. Finding a UX that maximizes the number of users who feel productive is going to help attract users to the product, and money can buy the design expertise needed to find that UX.
It might be the case that users only feel more productive with a given UX and aren't actually more productive with it. Even then, if a majority of potential users think that the UX is making it easier to accomplish their goals, a project will have an easier time attracting users.
The age of web changed all of that. Instead of being stuck on your computer with whatever tools you could obtain for it, you could now access centrally-maintained, quality webservices.
The FSF realized the freedom risk that centrally-maintained services posed, and created stuff like the AGPL to address it, but there just isn't as much leverage for that to take off like the GPL did.
This line has very bizarre consequences: FSF-supported hardware prefers closed-source firmware to be fused into ROM rather than upgradeble, the theory being that manufacturers shouldn't have more freedoms than the user. My favorite story was a laptop recommended by the FSF went from being "free" to "non-free" because an engineer found an undocumented protocol to upload new firmware to memory that the FSF thought was fused shut. These are the weird results that emerge when extrapolating extreme fundamentalist social policies far beyond their breaking point.
The FSF and Stallman do not care about the AGPL that much, they are far more worried about non-free software running on your own machine, like non-free JavaScript. Otherwise, Stallman couldn't ethically ride the T.
To Stallman, your counter-argument is a non-sequitur. His goal is maximizing user freedom. UX may be one dimension of user freedom, but at best it's secondary to certain prerequisite freedoms, such as the freedom to modify code so you can independently improve it, perhaps by improving UX for yourself and your community.
Many people sympathetic to Stallman, but more utilitarian, might argue that in the long term, user freedom is necessary for achieving optimal utility (e.g. UX, etc). And getting there might require short-term sacrifices in superficial aspects like UX.
With as many open and closed options that exist out there, competition is a thing and Open Source as a whole needs to compete on more than just being "the freedom option"
Stallman's valid points are entirely lost in the ocean-full of software like GNU Image Manipulation Tool that incite frustration from users.
Except that's exactly what human behavior does.
Very few people in the world, even most FOSS contributors and developers, share that belief that strongly. They might feel like FOSS programs give them certain advantages and rights, but morals? Stallman has mentioned that he would rather go homeless than run proprietary software. That level of devotion is exceedingly rare.
To approach someone, even a Linux user, and tell them that they need to give up their convenience for free software because what they are doing is immoral, that's a very hard sell. This is one reason GNU has mostly produced free software clones of better, commercial software, where practical concerns take a backseat to GPL.
I would argue this is only the case because we've created an intentional social and skill gap in the industry between server administration and operations work and software development. My experiences, especially more recently, have been shocking in how little the average software developer knows about /very basic/ server administration. I don't have a full picture of why this is, but my gut is that part of the reason is that this type of work has become socially considered to be beneath software developers. They see it as the type of thing you're supposed to outsource, scut work for digital janitors, so they never bother learning it. There's definitely a growing sheen of disrespect in the industry towards those very valuable skills.
The outcome is, yes, it may feel impractical to do things yourself. The reality is, it's probably never been easier to do things yourself. Everything from the widespread availability of low cost enterprise-grade hardware to the plethora of virtualization technologies and associated low-cost hosting platforms means that doing things yourself has never been easier than it is today. Yet it feels so far away because software developers in our current time are no longer the tinkerers they once were, preferring to focus on abstractions over dig down into the dirt of reality.
I think the best way to resolve this challenge is for individual developers to come down from their horses and learn the basics of system administration and actually try this stuff out. You can learn nearly 80% of what there is to know about systems administration and operations with an Ubiquiti router, two Raspberry Pis, and Google given enough time. But so many devs would rather use dubious SaaS tools rather than learn how to host their own Gitlab instance or run their own CI pipeline in their closet.
I use mkcert[2] for this but it's still fiddly.
[1] https://letsencrypt.org/docs/certificates-for-localhost/
Why run your own server, and keep it patched, and keep it secure, and configure the firewall, and all that stuff which spells doom if you get it wrong... when you can use some cheap or free service that does all the hard stuff for you?
I'm curious how much of this shift is purely because these tools really are better, or how much is due to an intentional marketing effort to make the DIY approach seem bad/unsafe/difficult/fraught with peril. I guess at some point it's a self-reinforcing flywheel. People think DIY is hard, so they actively avoid it, and tell their friends "running servers is hard, don't do that."
I used to know quite a bit of that stuff, had a series of jobs doing it. I gradually moved from C89 to modern c++ over the course of about 25 years. Easy stuff, when you use it daily. But when it's not my job to do server admin, that stuff evolves too fast to stay on top of. For me it's not a high horse, rather, a wagon that I fell off a long time ago
Why bother installing k3s and whatever deployment-tool-du_jour it is these days, when dropping some files on a host is good enough?
The issue isn't that people need more than a LAMP stack, it's that for some reason software developers in the 2020s are scared to or think it's beneath them to install a LAMP stack of their own.
Modern computing environments aren't very good, and most of the core abstractions haven't changed / improved since the 80s. Those core abstractions have so much stuff built on top of them now that they're very difficult to change. You used to be able to make a usable operating system in a month or two if you knew what you were doing. Now a simple web browser takes 20m+ lines of code to make. Its out of the hands of anyone with less than $1bn or so to spend - and at that scale the only real contributors are big tech companies. Except for some small features like io_uring and device drivers, linux is developed as if its already feature complete.
So I worry - will we ever replace the crufty parts of POSIX[1]? Will we ever have operating systems and software that can properly take advantage of NVMe and Optane memory[2]? Will we ever have desktop computers which sandbox software by default like my phone does, so I don't have to trust every program, npm library and rust crate on my computer with my data? Will there ever be a desktop class UI library which works across all my devices, or are we doomed to waste 90% of our computer hardware keeping electron + javascript fast-ish?
I'm worried these ships have sailed, and our grandchildren are destined to inherit a computing experience of electron, + more CSS.
In the 90s people would iterate on this stuff by just hacking linux and submitting patches. Now thats really hard because of how tall we've made our mountains of code. By the time you've climbed one mountain, you're halfway through your career. I mean, how many kernel hackers out there are also good at making user interfaces? How many people with frontend experience are even capable of hacking on linux? Its impossible to improve the interfaces between our systems without a holistic understanding. And thats becoming an increasingly rare commodity.
[1] Eg fsync(), and in my opinion the filesystem abstraction as a whole.
[2] Eg https://www.usenix.org/conference/atc20/presentation/bittman
No, probably not, as much as I would love to, because there are still people who believe that POSIX's design ideals are to be aspired to, even as the world has aged heavily around them. The POSIX model and philosophies are very outdated, but as long as people see value in the nonsense that is "everything is a file" (except for all of the ones that you can only ioctl to) or "do one thing and do it well" (except text parsing, that famously secure and not at all haunted thing apparently belongs in every app), we won't see big shifts in production OS architecture. Maybe research kernels, but those don't run PostgreSQL installs.
I don't think that has anything to do with this complacency, however.
For sure, many of us don't use OS where POSIX has any relevant meaning.
Yes, there are embedded OSes (l4); ibm i&z; etc. (L4 and ibm i are actually super cool.) But those are tiny drops in the bucket and aren't replacing linux any time soon.
ChromeOS and Android? POSIX APIs are not exposed to app developers.
Cloud? Language runtimes and serveless make POSIX irrelevant.
IoT? Linux is largely irrelevant in the world of real time OSes and bare metal language runtimes.
Desktop? How is that 1% going?
IoT is even more of a niche than desktop.
And, I think you underestimate the amount of software written in c, directly against posix.
Since then, language runtimes have spared me the effort, and I am not alone.
The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS.
But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're certainly still paying a cost. Plenty of benchmarks have been made over the years showing how better APIs can yield 20+% more filesystem & TCP socket performance on linux by bypassing write() and friends. If you spend $10k on a database or application server, think about it as $2k of that hardware wasted simply due to bad kernel APIs. And I'm sure there's plenty of features postgres and sqlite don't have because their devs instead needed to spend their days in a desperate struggling to make their software work correctly, at all.
Aside from performance, in my opinion a better API would also be transactional, at the filesystem level. Aside from dramatically simplifying every database, that could also would allow collaborative editing through simple network shares. I don't even think it would be that hard to do.
A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)
Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)
0. https://fuchsia.googlesource.com/docs/+/dart-docs/dotdot.md
1. Because plan9 does a better job than unix of making all resources files, inability to access some subset of files is a stronger guarantee.
In fact, there are special derived classes to handle file system specific semantics, if one feels inclined to do so, but that doesn't mean they work all the time, as JVM runs anywhere.
https://developer.android.com/ndk/guides/stable_apis
> Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.
Better learn how much POSIX Android actually allows.
How's that? It's a posix api among many others which is implemented on android.
How about fork[0], which is one of the more maligned posix apis (as far as I know, no one has any big problems with pthreads). Or errno[1]. Lots of ugly garbage in android...
0. https://android.googlesource.com/platform/bionic/+/refs/head...
1. https://android.googlesource.com/platform/bionic/+/refs/head...
APIs that aren't part of NDK stable API contract are not allowed, and since Android 7 Google has started to implement security measures to kill processes that try to use private APIs, one of the reasons why termux is no longer.
Good luck using your beloved POSIX APIs and not being killed in random Android devices.
According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax.
[1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.
By the way, since C11, there is no need for POSIX threads any longer.
C11 threads might be implemented on top of POSIX threads, or anything else that the compiler vendor thinks of.
This caused a distraction from the point I was making - which is that there are other ways we can do computing that don't use this model for files at all. For example we could make file operations transactional, or make files semantically rich - like database objects. So files themselves aren't "buckets of bytes" that need to be parsed by each application which interacts with them. There's lots of other ideas in this idea space - but the yoke of millions of lines of legacy code makes it difficult to explore this space outside of toy programming environments. And I worry as a result we might be stuck with the unix model forever.
Eventually other things in life are more relevant and all that idealism fades away.
Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone.
It won't be tomorrow, but it will come.
I disagree. Linux has reached critical mass, the biggest tech giants depend on it heavily and are the main contributors. If some new fancy subsystem, interface or syscall would benefit Google's workload, they will implement it and it gets merged since even of Google will be the only one using it, that automatically means it has millions of users. You come along with a not completely polished and thoroughly tested Lego mind storms usb driver for Linux today, you'd get laughed of the mailing list, because security and who will maintain that? I mean security is good and stuff, but Linux is a commercial product today and nothing a curious 16 yo can get involved with like in the early 2000s.
> It won't be tomorrow, but it will come.
I mean if you're talking decades here you're probably right but then again that also will hold true for Windows, Chrome, HTTP/3 and basically everything.
This is simply not true. Even the new N64 port got merged even though it's not very practical.
> because security
As long as your module is not enabled by default, there is little security concern with it.
> who will maintain that?
Well you of course. Having someone who maintains it is the biggest factor in deciding whether code will stay or whether it will go.
Check Android and maker distributions for how much gets merged upstream.
The only guarantee of the future is that it is unpredictable.
Yet here you are making predictions...
I doubt Linux will fade away until there is some major paradigm change away from Van Neumann architecture. It has survived and become dominant over 30 years by constantly adapting and innovating.
FOSS will outlive us all.
Go spend some time trying to get RHIDE working, for instance. You're going to have to bring it back to life to do so.
And yet, closed source seems to run just fine in emulation.
Good luck emulating! That emulator's probably based on FOSS. :)
With the emulator, first you need to write that emulator, and then you only get precisely that version of the software. After that, you're toast.
Right now I can double-click an icon on my desktop that launches SimCity for Windows 3.1 inside of dosbox, and it works great. It didn't take much effort to get working, either.
I can't say the same for most dead FOSS that I've tried to resurrect. Usually I'll have to manage the outdated dependencies somehow, perhaps by writing a SHIM or somesuch; and probably significantly fiddle with the build system because Linux systems have changed significantly since the mid-90s.
It's a difference of hours versus days of effort. I've done both, but guess which I simply _haven't the time for_ now? I've got family and friends that need my attention moreso than a dead piece of FOSS no one but myself seems to care about.
But if you wanted to, you _can_ update dead Foss. Can't update that copy of Simcity, can you. Nopers.
Summarizing, closed source projects die. At best you can run them in an elaborate museum (emulator) and at worse, you can attempt to Frankenstein's monster them by injecting DLLs.
Open source will outlive us all.
How many places does Doom run?
Doom is a closed source game that was finished, polished, and then open sourced. Strange to use that as a FOSS example.
The FOSS-from-the-start examples would be Tux Racer, 0ad, and so on.
And the emulation argument can also be made for old open source software, so I don't see how that supports the argument for closed source.
Maybe I just got lucky, but so far I've only ever "lost" CS software, example see above, but never OSS.
In the specific instance of GitHub, I have to agree it's nicer and better polished than the alternatives, but I'd also say the Free Software alternatives (GitLab, SourceHut, etc) are catching up, and are already usable. Hosting your own GitLab instance gives you a far nicer solution than an old school solution like SourceForge.
> we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day
People are paid to work on various Free and Open Source software projects, including Firefox and Notepad++, and most famously, the Linux kernel.
This is why I continue to be fascinated by FreeBSD, I don't use it for much but when I do, what I'm trying to do almost always works right out of the box.
My point is that is all comes down to packaging, which is done everywhere. Docker is so popular because debian-style/rpm-style/etc packaging systems and the maintainers of said packages do a pretty uneven job of making things work without luck or fiddling (or having to have package specific knowledge about how to do something obvious). Docker doesn't really do a great job either, but it has a different set of problems and having the old ones gone is nice.
No you don't? You can throw it on a random commodity desktop and expect it to work. I imagine laptops are harder if you want suspend etc. - it feels pretty similar to how Linux was a few years ago. (If anything support for old hardware tends to be better than Linux because they don't keep changing the kernel interfaces, so a barely-maintained driver from 5 years ago is probably still usable). You don't need to use it in some particular way, it's fine for a daily-driver desktop or home server. I used mine for a little bit of everything until recently - ordinary KDE desktop, fairly normal web hosting environment running some stuff I wrote in Python with WSGI, database server, home VPN server... all the usual stuff.
It is true that FreeBSD is slower to get new hardware support but I actually like that, it's one of the major reasons why things just work in FreeBSD. You put the work in upfront, select the right hardware and FreeBSD will serve you well for years with very little effort.
They aren't chasing some imaginary/political/technological dream they are delivering high quality software using tried and tested methods.
Debatable. As a previous paid customer, I have never been a fan of GitLab, I've always found it slow, buggy and of confusing design language. YMMV.
Getting new contributors is overrated for OSS unless they are an exceptional contributor (like if a big org were to contribute).
Main incentive is getting more consumers of the project (increase popularity) and making it more convenient for current team.
If a project has self hosted infra and wants me to sign up to their Bugzilla I think twice before doing so.
And if github really turns to shit because Microsoft shows their true evil face you can just move platforms again.
https://gitlab.kitware.com/users/sign_in
or
https://gitlab.xiph.org/users/sign_in
You can sign up with your GitHub account.
Further when something gets reported to GitLab they automatically close old issues and things never get fixed. One outstanding huge issue is that if you mark certain files as owned by a specific team for example, it won't notify the teams to come in and actually review the code. There's options that say they do it, but it never works. (The notification system in general is an utter mess.)
GitLab is an example where everything is chopped up into tiny pieces and nothing works across different parts of the codebase. I don't envy anyone that works for GitLab as just the look of the code shows what a mess the backend must be.
1 - https://docs.gitlab.com/ee/user/project/code_owners.html#int...
2 - https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-rel...
It's easy to manage either via Helm or omnibus packages, and does a ton of things well enough. It still has significantly more features than GitHub.
> So we’re moving to servers we don’t control, which does make me nervous, but the argument goes like this: Microsoft owns GitHub, and it’s highly unlikely Microsoft is going to go bankrupt anytime soon. If Microsoft pulls the plug on GitHub, it’s not just SDL that would be in trouble, it would be the entire open source ecosystem, so interested parties would move fast to help you migrate to somewhere else…right?
Gitlab Inc. is dramatically more likely to go out of business that Microsoft, and Gitlab generally is dramatically more likely to have significant outages than Github.
I don't understand why things like vulnerability scanning needs to cost $80 per user more and then at the same not supporting multiple report files as artefacts in monorepo.
I gitlab significantly harder to use and more error-prone than Github
Like john_cogs, I'm also a GitLab team member, and am part of the Community Relations team. I run the GitLab for Open Source program. I joined about a year ago and am really impressed by how fast GitLab moves forward. We have a lot of awesome stuff coming up to make the product, and our community, even better.
With a release each month, we use our momentum to make big strides in the DevSecOps space -- so people can rest assured that we'll keep improving quickly! We like to build along with our users, and believe everyone can contribute to our product roadmap, and all aspects of our company (e.g. see https://about.gitlab.com/direction/).
For OSS projects considering a move, check out this GitHub vs GitLab Decision Kit: https://about.gitlab.com/devops-tools/github-vs-gitlab/decis... It outlines some of the key points to consider when evaluating a move.
I'm also happy to answer any questions about the GitLab for Open Source program john_cogs mentioned below (https://about.gitlab.com/solutions/open-source/). It's a great deal in that OSS projects get 50,000 CI minutes for free along with our top tier in SaaS or self-managed. Feel free to reach out to opensource@gitlab.com with any questions!
1. Fix their bugs instead of new features (ex: rebase fails 9/10 time for us) 2. Fix their pricing (ex: $99 per user is way to expensive and that is the only plan that allows free users)
You’re answer is the stereotypical answer of telling the user to adapt to the tools instead of improving the UX (not to mention completely ignoring my point that GitHub doesn’t support stacked diffs). GitHub has a lot of advantages and has maintained their community but they lack pretty badly in some ways on the usability of their UX flow/feature set for power users. This isn’t necessarily accidental or a wrong decision since they might be prioritizing the broader dev community that isn’t familiar with more opinionated dev workflows and they’re solving the Ux for 90% of PRs. I still think there’s a way to strike that balance better and I hope they do so so that I don’t hate my life whenever I’m forced to use GitHub.
> One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure.
This is still a good policy to have. They've already done the work to migrate from mercurial to git so, the potential for moving to a forked gitlab or something like that is there. Personally I think that, especially if your doing open source, github is really the way to go here. Github has been great for open source.
After Wayland support was added, I was trying to add support for running SDL apps inside the "fullscreen shell" style compositors (compositors meant to nest other compositors or run one application fullscreen).
I'm not asking in bad faith here. If there are such dangerous I would very much like to know them.
Now some years later there's a blog post from Github, "An update to our free tier" that outlines dramatic changes. It turns out Microsoft needs to make some changes to keep their shareholders happy with their returns. Now Github only allows 2,500 issues per repo on the free tier--you'll be wowed with slick graphs that show for 99.999% of users they'll never even know or notice this new limitation. People will post long comments on the Hackernews thread about how 2,500 issues ought to be enough for anybody and that Github/Microsoft actually love developers _more_ because they're willing to reduce the features than shut down the business.
And now SDL is in a bind.. a free project that generates no revenue now is facing a dilemma. Should they pony up real dollars to keep the history of their 25+ year old project? The cost of moving source control isn't trivial and is a huge ops burden that keeps the devs from doing real work... and cha-ching out comes the credit card, out goes a $100/mo then $200/mo etc, etc. charge.
This isn't some wild speculation, look at Microsoft products like Onedrive that clawed back huge free tiers of storage in the past. It's just an inevitability with commercial software that costs will rise and someone will be squeezed for money.
Do me a favor, look at Facebook [1], Apple [2], Amazon [3], Netflix [4] and Google [5]. Now tell me which one has more Open Source repos than MS [6]. I'll give you a hint... none of them. Sure, volume of open source repos may not be the best metric, but to say in 2021 they are enemies of open source with almost 4k open source repos is just dumb.
Hell, even the new MS terminal [7] is open source. They realized that FOSS isn't the enemy and is actually good for the tech industry at large.
[1] https://github.com/facebook [2] https://github.com/apple [3] https://github.com/amzn [4] https://github.com/Netflix [5] https://github.com/google [6] https://github.com/microsoft [7] https://github.com/microsoft/terminal
[0]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
> Otherwise, it's like "free" google products; here today, gone tomorrow.
Respectfully, I disagree... google products are introduced as services, not open source and they shut them down often. If an OSS project is useful and has community support, you can always fork it.
The fact that Apple is trusting MS with their source code really should tell you that your open source project will be fine. What you'll want to watch out for is when these other competitors decide to abandon ship.
Counterpoint: No they aren't. Counting Git repos is totally nonsensical, and open sourcing their terminal is a meaningless gesture, but I guess that's enough to fool some people.
Microsoft has a very, very long history of being a shitty company. Fucking over DR DOS, fucking over Stac, war profiteering, patent trolling, up to the privacy dumpster fire that is Windows 10. That's just off the top of my head. And I've been around for all of it, so excuse me if I just don't fawn over Microsoft suddenly claiming to be the good guys now. Trust is hard to earn and easy to lose.
Rather than fighting the target directly, they are embracing it at first; and this time, the target is open-source and the developers. They are doing it again and are targeting where the developers are: Hence their involvement with GitHub, Xamarin, Linux Foundation, Chromium (MS Edge), WSL 2, VS Code, TypeScript and Azure and it is working for them.
The company has not changed. Only the target has, and they are already embracing them and slightly started to extend.
If you look at current MS, it is all about services. Services do better when you have a larger addressable market and not embracing OSS will reduce who they can sell to, which is why they are going to.
VS Code is a perfect example, MIT License... OSS, wide support and well regarded.
Each of those may appear small by itself, but they combine into a significantly better experience for contributors.
OMG I feel heard. I feel like this is me.
A hosted version is also available: https://foss.heptapod.net/public
Works like gitlab, but on top of Mercurial. Use it myself and it works perfectly.
Presumably you'll know then.
> It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.
The bar has been raised for developer tools in 2021. The OP recognizes it, it's true.
The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially.
It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure.
(It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...)
And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in.
We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted.
But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to.
The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.
I will say too don't expect these hosted services to free you of operations burden. On the contrary you're even less connected and more at risk of operations burdens when these hosted services are facing issues. When Github actions CI/CD is acting up, or the hubot issue manager isn't working, or the release artifact store doesn't have the bits you expect, etc. your entire project grinds to a halt and it's not easy (by design) to eject out and work around them. Projects that depend heavily on all these hosted services are going to find over time that they need to buffer and insulate themselves from these centralized, single points of failure. It's just a different kind of operations burden.
If you started a FOSS project today with a mailing list wherein contributors mail you git patches, you would get exactly 0 contributors.
And maybe that's ok, maybe this is your baby, and if someone wants to push code to it they can learn how to email a patch to you.
But for many developers, they do want to have some of the load taken off of them by other developers. They want to reap that benefit of OSS.
Oh, you'll get complaints, that much is very achievable. But actual contributions? Even simple, bullshit code boot camp homework exercises? Good luck.
But, sure, if you don't care about making the development tools something that anyone other than you find convenient, than you can of course just pick whatever you find convenient, nobody is going to stop you.
That's still not a mailing list with patches for most people, but if it is for you, that's great, nobody's going to tell you you can't do that.
The OP said he was switching because he thought their current systems were taking too much of his time to maintain, and were still too hard to use for other collaborators.
You seem to be trying to tell him he's wrong and those systems didn't really take too much of his time, and he actually didn't have any other potential collaborators anyway.... it's a weird argument.
You've misunderstood, the coding boot camp assigns homework, and sometimes that homework is: "Contribute to an open source project!" This usually takes the form of something like a pull request to "Fix typos in README" or something otherwise insignificant. GP is just saying that however you release your FOSS project, you're unlikely to get even that tiny level of outside contribution, so using "no one will contribute" as an argument against a mailing list isn't very persuasive. The argument that mailing lists suck, perhaps more so, but GP didn't opine on that.
I think you are unlikely to persuade them to change their minds with an argument in an HN comment, but you can keep trying!
Self hosted gitlab is nice, until you realize that you can get the same functionality for free from Github and any second of devops spent on your self hosted thing is technically just money down the drain. In our case, I got a little worried about our flaky backups and the fact we were using a single node vm in AWS to host this. The fix would have been increasing cost by spending on more vms and devops. Instead, we switched to Github. And that was before they had free plans with unlimited repositories and developers. We actually paid for it and saved money (not to mention stress). These days it's a no-brainer because at 0$ per month you get source hosting, CI via github actions, and all the rest. I'd actually gladly pay for it before considering other options. But it seems MS has decided that's not worth the effort.
The thing with OSS is that it's not the world you want but the world we all build together. Plenty of people that want stuff but rarely enough that go out there and actually build it, persist with building it, find the right people to collaborate with to get things done, and then collectively deliver results. That takes a platform to collaborate on and for better or worse that platform is Github and git.
Mercurial just never got of the ground as a mainstream solution and fell behind as Git got more popular. It had a shot as long as it was the third option (along with subversion and git) on Sourceforge before Github was a thing. But then Github happened and offered a nice UI for pull requests and that turned out to have been the killer feature developers wanted and needed.
> And the way that most people personally like using git is via GitHub.
I don't get it. In which way? I use GH for pull requests, may be issues? There's a lot more of my git day to day than that. I don't think you really use git via GH.
But it is so much more than just Git hosting.
> "It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable."
For example, ReactOS's source is hosted on both GitHub and they have a self-hosted backup which they control in case GitHub goes down. If this was SDL being GitHub, so far they don't have a backup plan. Pull requests, issues and their GitHub actions will not work and they would need to wait for GitHub to restore their services or do 'anything'.
I prefer 'Owning all of your own infrastructure' or even being on GitHub and having a self-hosted backup of your own infrastructure just in case GitHub goes down. But moving everything and being 'all in on GitHub' is the ridiculous quest to centralize everything on a platform you don't own because everyone else is doing it.
To those who use mercurial over git, why?
Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things:
- hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will automatically rebase all the commits on top of the commit being split, ofc
- hg histedit: a sort of "git rebase -i" where you get a list of commits that you can manipulate by reordering them, merging, dropping
- hg amend -i/commit -i: interactive commit or amending of a commit, it's using that awesome interactive patch editor I mentioned earlier to select what exactly gets committed/amended
- same for "hg shelve -i" (a sort of "git stash")
The closest thing in Git to that interactive patch editor was doing "git add -p" which is not as good.
[1] https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
I think Visual Studio Code has something of its own. Would be great to have that part of the Git command line, but I guess shouldn't be hard to make one, considering its already out there on so many IDEs.
A couple others mentioned Magit which I think is similar.
FWIW I learned Mercurial before I learned Git, and SVN before that. Mercurial was great. I still think its commands made more sense than the Git ones, especially coming from SVN.
Same with histedit, that’s in magit as well.
Pijul is very promising: https://pijul.org/ and https://pijul.org/manual/why_pijul.html
Merging A in B should yield the same result as the opposite with Pijul, etc.
Ubuntu might still use Bazaar.
Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much.
GitHub, however, was what drove git.
Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
Powerpoint is optimized for marketing and not much else. It exists because of two reasons:
1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them.
2) A lot of business presentation IS marketing--and Powerpoint is fine for that.
The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
I'm a big fan of chalk talks for anything mathematical. I find it hard to stay engaged with slides, even if the presenter uses tricks like revealing one step at a time, annotations, etc.
This is a version control misfeature/bad practice.
It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it).
And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git.
Heck, I'd "accuse" you of rewriting history right now :-))
I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.
Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.
GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.
By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
Took a bit to dig up with Google their 2011 announcement that they're now also supporting Git. https://bitbucket.org/blog/bitbucket-now-rocks-git
(Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
A lot of software development got a lot better. Yes, software development was possible before GitHub, but it lowered the barrier to entry a lot.
hg added stuff to match git's workflow but it isn't hg's default. The tutorials for hg all teach a decidedly inferior workflow to git.
ps: did a 20 person year long project in hg first, next project was git. Not going back if I can help it.
Curious as how it's "better". I have in all honestly only ever used git.
I'm probably going to be wrong/off on some stuff, but this is what I remember from the old days:
* Mercurial had a better CLI by default -- it was closer to SVN, which made it easier to use, and it was designed so that you had one command that did one thing, whereas git was more flexible but you needed to remember a lot of option flags. * Mercurial had better early GUI client support (this changed, but early on, I know this was a draw for me as a Mac user) * I'm pretty sure Mercurial had better Windows support (I didn't use Windows so I can't speak to this, but I seem to remember this) * Better documentation
But git has evolved a lot over the last decade plus. Not only did GitHub really change the game by creating a more social layer on how to contribute/use git (and yes, I realize GitHub != git, but it definitely helped introduce a lot more people to git), it had features that really honed in on some of the pain points git had compared to Mercurial.
Although BitBucket was sort of positioned as a GitHub for Mercurial solution, it never achieved the organic/viral adoption of GitHub. And when Atlassian dropped hg support last year, it was pretty much confirmation that git "won."
Other than Facebook, I can't think of any major companies that use Mercurial or major projects that use hg.
I used to be sad about this, because I felt hg was better designed, but I came to terms with the reality a long time ago. It is what it is, and version control is often something that network effects define. Use whatever you want for your projects, but git won.
Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.
Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.
Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit".
The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets.
This is not a good example to base ”much better UI” claims on.
I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things.
It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git.
In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system.
Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.
Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane?
I could go on and on and on ...
However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(
Ever dealt with someone who has a specific breadcrumb trail for making changes to WordPress, for example? "Staging" is an extra set of steps to his breadcrumbs that can go wrong.
The staging area is useful to a small number of people like you in return for complicating the life of everybody else.
1. I changed my environment URL because I need to test on a specific one.
2. My actual feature changes, couple of files and a hundred lines changed.
3. A bunch of debug print messages, some are intertwined within the changes in 2, and some are in other places.
I will stage most of things in 2, probably in multiple commits to group logically. Most of 1,3 will simply be discarded once I comment and test final version. 1, might stick around for the next features I work on.
I can not believe this is too much state, nor can I believe this is not a fairly common workflow for developers?
How would you do this without staging? Would you discard the temporary changes and commit, then possibly write them back manually?
—-
I appreciate the Wordpress example but I’m not familiar with it so it flies right over my head to be honest.
One thing I liked, that most do not is they had both git style branches in the form of tags, but mercurial had "real" branches.
With git you can see this if you merge things back and forth then remove the branch names. There is no way to tell which commit was on was which branch. You just have the graph of commits.
This is not true of HG, it is always there baked into the history.
edit: I can’t remember where, it was when I was researching fossil, but there are some good reads on why Linus created git and the history of VCSs.
[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution
combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history.
there is also the very powerful revset DSL for finding revisions and/or files.
IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather than pepper the devs/issues/comment threads/etc. with pointed questions, "Why did you do X when Y is now clearly better??".
https://en.wikipedia.org/wiki/Mercurial#History
i would guess you are right, though, that at the point SDL chose Mercurial (I don't know when), git hadn't achieved the market domination over mercurial it now has.
[1]: http://forums.libsdl.org/viewtopic.php?t=6047 [2]: https://discourse.libsdl.org/t/sdl-in-subversion/13289
Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform.
If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects.
[0]: http://wiki.libsdl.org/MigrationGuide#If_your_game_just_want...
Running a git server is actually very easy, just run the git-daemon command: https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon This is actually easier than running something like Gitlab that requires setting up a database, a reverse proxy, or even an entire runtime environment like Kubernetes, etc.
You're falling into a trap of conflating git with Github. Github took the mechanics of git and built a slick, centralized, commercial source code host on top of it. They made a social network that engaged users and gamified writing code. Lots of folks are working on similar commercial and open source variations of the same. But in all those cases git is just a part of the tech and not tightly coupled to the success (or failure) of them.
But self hosted Gitea and other alternatives won't scale easily (and would not be cheap). The biggest attraction to Github for me is the user base and scale, not the UI/UX.
GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.
Basically, if you think your home grown infra sucks, a GitHub mirror doesn’t address that.
I'm just saying you don't need to be fully on GitHub to be visible on GitHub.
You can confirm this by reading one of the bot replies to a PR [0]:
Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.
[0] https://github.com/torvalds/linux/pull/805#issuecomment-5933...
Thanks for the correction.