Kyoto project is moving from GitHub to Sourcehut
github.com
github.com
Why support Github when there is st.ht? Why support Starbucks when you can support a mom & pop coffee shop? Why buy books from Amazon when you can buy from a Indie book store? Granted, not everyone has the patience, time and money to vote with wallet, but we can try wherever possible. I hope more people ditch Github
https://todo.sr.ht/~sircmpwn/hare
The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.
That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network.
The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part.
In the future gitea, srht, and many other implementations could interact with each other's users.
SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting.
I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated.
I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
From the sounds of things he does not want the feature.
If you and several other people happen to have a hard requirement for a specific feature that he (or his buddy Simon) don't see fit for, you won't get that feature, even if you volunteer to implement and maintain it. The only thing you're left with is basically to fork SourceHut, host it yourself and maintain your feature all by yourself, dealing with continuously patching a very much still-in-development (and therefore ever changing) software. That is something you're probably not going to do, especially considering SourceHut's architecture and way of doing things.
SourceHut isn't exactly extensible/pluggable and hosting it as a one man show or even a small company becomes a huge PITA, as soon as you diverge from the holy grail that is Drew's way of doing things (Alpine, no containers, no good config management, no easy way to scale things, and the dedication to invest your blood and tears into maintaining this thing).
Hence I really cannot comprehend the current trend that is "let's all dump GitHub for this, and that, and SourceHut". So far, SourceHut really hasn't made an effort to prove itself worthy of the influx of OSS projects. And while I do see Drew commenting here, reassuring folks he won't ban anyone over any internet disagreement, reading the public mailing lists of the SourceHut repos doesn't really show much of a welcoming behavior either. I mean, he's the person behind what has become one of the most popular Gemini servers, and as soon as that was the case, he began threatening client apps to arbitrary block them for doing things that don't align with his values (in this case, [showing a favicon](https://github.com/makeworld-the-better-one/amfora/issues/19...)). And the cabal of elite internet Amish, that have been on SourceHut since its early days and that makes a large portion of the platform, aren't that different either.
I do agree with GitHub being the wrong place for OSS projects, but I don't agree with SourceHut being the right one. At least for as long as it doesn't become obvious that its founder and the community around him has changed and started to genuinely appreciate people for the work they're doing, regardless of their own ideological beliefs.
That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758
I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
I'll take another look.
Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
I've had Google silently swallow emails before, both sending and receiving. It's not fun.
That was just one example, I've seen corporate Exchange systems do the same. Are they not professional?
If one of the biggest email providers on the planet can silently swallow and not deliver emails, then blanket statements saying emails never fail are just wrong. It's important to understand practical failure modes of the systems we use, and not pretend they're more perfect than they are in reality.
The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses.
In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead".
Maybe this is too idealistic?
No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
Let me start by telling you a story about me trying to buy clothes for the first time:
Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality.
After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly.
A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use.
So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big.
I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page.
What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making.
For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers.
It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service.
What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default.
But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered.
I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.
Why not buy the best product at the price you're willing to pay for it, even from a company with the values you share? Where does company size take precedent?
> A very rich, multi-trillion dollar asshole-ish corporation, that feels lonely on it's birthday and goes on a bender buying less rich and asshole-ish companies to successively kill them, to calm it's mood.
Not sure how true that is, but something tells me it might just be the reality.
If you don’t make an effort to try smaller company’s products, you’re going to be biased towards bigger companies by virtue of them having better marketing and network effects. Some conscious preference to smaller companies can help counteract this.
And even if the smaller company has a worse product initially, some people using it anyways can help keep them alive in order to fund innovation. Smaller companies tend to be more willing to experiment or innovate, but that can’t happen if no one is willing to make a long-term bet.
Having said that, I still buy a lot of things from Amazon because it's much more convenient than the alternatives. It's a habit I've been trying to kick, but I have a ways to go.
Of course a homogeneous world is less interesting. And anti-competitive behaviors are net bad and need to be disincentivized. Big company hate just seems misplaced.
Remember OVH server room fire? Was there any failure of such magnitude in AWS/Azure/GCP?
It's hardly surprising that low cost options are more prone to failures in many markets.
Github is about 1000x more user friendly?
And the big ones don't ever do this? You're probably shielded from the jira ticket backlogs that are thousands deep.
While there's no hard and fast rule, small companies tend to care more, as they're closer to the pain. A loss of a customer isn't just "churn".
We should strive to have at least four to six alternatives for every type of system. It keeps pricing competitive, gives users lots of alternatives, and prevents single players from strong arming behavior.
Right now there are too many monopolies and duopolies in tech.
https://sourcehut.org/blog/2022-04-08-2021-financial-report/
SourceHut is profitable and sustainable, thanks in no small part to the fact that we expect users to pay if they have the means. Small companies providing free services with investor subsidies are much more likely to disappear than a company with a service you're paying for which isn't beholden to any investor demands for infinite growth.
Hi Drew
I’d encourage you to start charging then based on your comment above.
Because sourcehut pricing page currently says “payment is currently optional”.
You’ve been in alpha for a few years now and I’m sure many of us would agree it’s totally appropriate for you to start officially charging based on the quality of your service.
IIUC your report, you are paying developers (and yourself) only USD $30,000/year. The typical software developer would make at least three time that much elsewhere. With 3x salary, I'd say SourceHut would no longer be profitable or sustainable. Or am I missing something?
https://sourcehut.org/blog/2021-08-23-work-at-sourcehut/
The sustainability metrics are based on revenue covering the small base compensation plus operating expenses, as well as having a large enough standing balance to weather any unexpected events. We seek to make models which guarantee the longevity of the platform, and prioritize making sure that our cash flow will always provide for operating expenses. If our revenue dropped to zero today, we would be able to run the platform for several years.
Ultimately, everyone involved in SourceHut is there because they believe in free software and believe in the model we've designed to further its cause. Our non-negotiable ethical standards calls for a creative business model to make this thing work.
The work experience and impact we offer is something that is, in my opinion, completely unmatched in the industry. It's not for everyone, but we believe in what we're doing, and it's worth taking a gamble on an unproven business model.
If you want the only guaranteed probability about the future: its that most predictions about the future are wrong. Everything dies eventually; the things you least expect last longer than you expect them to; or sometimes much shorter. I do feel pretty confident that both Github and sr.ht will be operational tomorrow. But, not 100%; and even less than that next Tuesday; and even less by September.
Actually, Github has had 12 public incidents since May. So... maybe I shouldn't be so bold with my predictions about Github's operational status.
When people say "something is unlikely to happen" what they really mean is: I really hope that thing doesn't happen. Me, personally; I hope both Github and sr.ht continue to see success. As you say; me choosing to pay Github $5/mo won't change anything for the better or worse; but paying that to sr.ht, now that impact is much bigger. If you distil it down to the manifestation of your own hopes: I think the choice of who to support is obvious.
Github has massive market share and may get expensive but is unlikely to die.
And that would worry people, sure, new owners may not look after it, etc., but there'd be plenty of time and warnings to move off it.
Say what you want about Microsoft, they do more than just search or advertising. If anything you are interested in from Google isn't search or advertising related, don't count on it lasting. The only people surprised by Wave and/or Wunderlist getting canned are people who haven't been realistically looking at who Google is and how they operate. The worst IT contracts I have ever had to administer are with Google - they are a complete joke.
As for "incidents" - lol - who doesn't have them? What's more important is how does the org in question respond to them. You seriously think sr.ht is going to have the same resources as github/Microsoft? Then again it's a dramatically simpler platform so that's a huge advantage as far as that goes - but just look at this thread; as they add more features the chances for incidents goes up.
I’m not super opposed, but Drew can be pretty over the top ideological/irritable for my tastes (at least that’s my perception from reading his blog). I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something. Yeah, I can back up my stuff, but at a certain point I may as well self-host.
The larger point still stands though. Instead of consumers simply supporting the biggest players in the market (because of convenience), it would be nice to give smaller players (who are not shady) a chance?
Has that happened?
But the FAANGs do that to people all the time.
[0] (I have no idea if Drew DeVault would actually boot someone off his platform for arbitrary reasons, though. I'd hope that's not the case.)
He basically ignores anyone who has or currently does work at any company he deems unethical (read: Google/Amazon/Facebook/etc). You're forever tainted in his eyes, and your opinions are always only useful if someone else agrees with you that isn't tainted.
Which really sucks because his entire software stack depends on the work (and opinions) of the people that he discards: Go, Python, and Git for a few.
He's not unique in this viewpoint. Quoting jwz: "As I've said before, if you work for Facebook, you should quit; it's the only morally defensible thing for you to do."
> his entire software stack depends ...
That sounds like the Mr. Gotcha meme: https://thenib.com/mister-gotcha/ . Again referring to jwz, his nightclub is on Facebook and Instagram because it's not economically viable to avoid them. ... Gotcha!
Similarly, it's hard to avoid all software which doesn't have influence from the big tech companies. I used https://github.com/swenson/sort ('Sorting routine implementations in "template" C"), and even this little indy package has contributors from Google Inc and the main developer worked at Google for a year.
DeVault's working on a new programming language, Hare. You could view that as having the long-term unstated goal of escaping unethical companies.
If so, isn't that also "over the top ideological"? After all, we know Apple's opposition to the GPL dates back to the early 1990s when NeXT used gcc for Objective C, and their rejection of GPLv3 caused them to ship ancient versions of bash, recently replaced with zsh, so it's not like they weren't aware of the GPL.
Some people use Linux (the moral equivalent to "self-host") to avoid Apple's ideological stance.
Which, from a business standpoint, makes for a marketing opportunity for a FOSS-aligned source code hosting company. Which takes us from an ideological position to an economics one.
(To quote Bill Hicks: “Oh, you know what Bill’s doing? He’s going for that anti-marketing dollar. That’s a good market. He’s very smart.”)
There's a wide gap between being irritable and being unprofessional. Nothing I've seen so far in regards to how SourceHut is being managed, indicate that you'd have such problems. (I'm saying this as a long time user of SoutrceHut and as someone that got into arguments with Drew)
I have strong principles and I stand steadfast by them. However, one of those principles is tolerance for different views. I want SourceHut to be available for everyone, even if we don't see eye-to-eye. You won't be booted off if you and I happen to end up in an argument somewhere online.
I've made myself personally available to users, as a person they can directly reach about problems and concerns with the services, rather than a support ticket answered by a random lackey. I think this is very valuable. Software is made by people. One of the risks that comes with this, however, is that people can start to view SourceHut and my private identity tangled together. Rest assured, they are separate, and I treat SourceHut with a great deal of deliberate professionalism and reverence for our users.
Nicely done.
About banning... thinking out loud...
I wonder if a public ban log would reduce food fights. Nothing too fancy. Maybe just date, account name, cite terms violated, optionally cite evidence, admin actions taken. No need for comments, discussion, whatever.
Then whenever the peanut gallery starts concern trolling, you can just link to the ban log entry. Instead of explaining yourself, yet again.
SourceHut is not a social network and does not have particularly arduous moderation needs. It's vanishingly rare for us to ban someone at all for this reason. We additionally provide banned users with a complete data export and tools to re-import that data into other SourceHut instances or instances using compatible software, so they are not left without options.
If someone feels slighted by moderation on SourceHut, I would invite them to speak publicly about it. I'm prepared to justify our actions in the court of public opinion with consent from the maligned.
Because small, local is not always better. It's quite common to find coffee shops here in the PNW that make a horrendous espresso. Most roasters here in Seattle are pretty mediocre and only capitalizing on the Seattle reputation. I can rattle off all the "local" and "small-batch" bourbon/gin/vodka distilleries that use sourced alcohol and are over-priced train wrecks powered only by marketing and no skill. At least with Starbucks, I get consistently bad coffee. I'm not risking over paying for coffee that I spit out.
Definitely have been looking at st.ht but if github fulfills my needs better, I'm sticking with that.
That's exactly what happened to me at Starbucks. I had to wait for a small cookie shop to open up in order to buy an overpriced decent espresso. They had an Illy logo which helped a bit.
In Italy and Greece you specifically want to avoid big chains as almost every small shop makes better coffee.
Interesting, does it? Obviously tastes differ, but I'm trying a tin at the moment because I ran out and could get it same day vs. waiting for delivery from my usual roaster subscription - I may as well be drinking any old thing off the supermarket shelf, don't find it superior at all.
Possibly the blend just isn't too my taste, it also doesn't seem to be as fine as I think I would grind it, but I think the main thing is freshness. Despite its vacuum seal it's still months old, vs. I usually receive beans within a few days of roasting and grind on demand.
Problem is that, I would say the majority of, small coffee shops in the US makes horrible espresso. Coffee isn't a craft to your average American no matter they claim, and they'll drink any swill. It's a way to get caffeine in you. Dark roast is the best selling roast.
If I go to a small coffee shop and they ask me what I mean when I order a doppio, that's when I start looking across the street for a Starbucks. At least Starbucks baristas are trained on what doppios are, and I'll get a consistently bad one. There's a very good chance that small mom and pop one will make me cigarette ash juice if they don't know what a doppio is. I'll take bad espresso over ash juice any day.
In the end it's an ideals tradeoff. Are you going to prioritize the growth of your project ecosystem but give into megacorps, or are you kneecap contributions by choosing esoteric ethical workflows.
Many a would-be contributor has lost interest when a project was entirely dependent on github, too. It's pretty telling when a contributor uses git, but can't contribute to a project that also uses git.
Small businesses usually treat their employees worse than chains do (because "we're all a family"). Also… coffee shops seem to have big opinions of themselves but the farmers do all the work. Baristas just have value unfairly credited to them by the customers because the product is addictive.
We hold ourselves to a higher standard than most and we have a specific and documented set of goals to accomplish before we declare the alpha complete. However, any potential user who wants to use SourceHut today can find a wealth of information to secure peace of mind in their choice.
Not hosting my code in servers of a company which is openly hostile to open source and Linux is a good move.
Lastly, you can try to prevent scraping. It’s a cat and mouse game, but at least your servers can’t be directly accessed by the training code itself.
I think Microsoft gives back to open source almost as much as they take, so I’m fine with them.
I disagree. I think that GitHub is training Copilot on only repos currently on GitHub, because they can easily do so due to the Terms of Service [1] which allow them to "parse [user content] into a search index or otherwise analyze [user content] on our servers". They can reasonably show that an ML model fits the definition of "otherwise analyze content", regardless of the license.
If code that was never hosted on GitHub to begin with starts showing up verbatim in Copilot suggestions, it might be a more legally challenging position for them. It is unfortunate grey area if people decide to upload copies of free software repos to GitHub anyway, but perhaps future versions of the GPL or other free/libre licenses could be explicit about usage in training ML models.
I have no idea what Amazon or Salesforce are doing, but it would be interesting to hear what they are using for training data and how they justify compliance with the software licenses.
----------------------------------------
[1] https://docs.github.com/en/site-policy/github-terms/github-t...
The user who uploaded the code did provide attribution. They could have uploaded that code as part of a vendoring. There is not some flag that says they are not the copyright holders.
Copilot trains on that code just the same.
More importantly, the fair use they are claiming seems to bypass attribution and licensing requirements. It need only access to the code.
That is to say that it can 100% train on code hosted elsewhere. Until this fair use gets challenged by lawsuits, it will hold true.
The fact that we have not heard of these lawsuits yet, at least to me, shows that lawyers agree it is legal.
If they are correct they don't have to follow individual license terms, if they are incorrect it makes no difference if they scrape or receive code because any complex project is a mix of many past authors not all of whom must be on GitHub.
If the courts don't agree then there is no penalty. It would legally be fair use. It does not matter what you or I think.
You are arguing that it is wrong, but very clearly many lawyers disagree with you.
I'm not sure if this is true. The US isn't the only jurisdiction in which GitHub/Microsoft operates in.
> If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
https://docs.github.com/en/site-policy/github-terms/github-t...
And those users indemnify GitHub, too.
So code that has been uploaded to GitHub by non-GitHub employees does have a “color” to it (to quote a great blog post on IP law that I can’t find right now) that other instances of the repository under identical licenses on other hosting services do not - because in theory the uploader assumes some responsibility for any dispute!
Whether this “color” has significant legal merit is beyond my understanding, but I have no doubt it is a factor in their approach.
> you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)
There is no mention of making derivations or anything that looks like it could cover for CoPilot.
There is a vague supposition widely believed that NN weights do no longer contain training data, and thus the trainee holds full copyright, but that won’t stand when the NN returns excerpts from said training data. Then it just becomes an unattributed copy, and should be subject to takedowns.
Here are links to Amazon and Salesforce
https://aws.amazon.com/codewhisperer/ https://blog.salesforceairesearch.com/codegen/
> including GitHub employees
It would probably be different if GitHub's employees do it at GitHub's direction, since in that case they'd be explicitly taking an action on behalf of their employer to pull in that code.
And either way, it's time to yet again to step around Microsoft's interference in the beautiful world of open source.
Honestly all this is fine but train it on your own code, you have the money to do that, and the scale, why bother us the small fish. What's the worse that can happen, you will have to maybe pay people to write code, maybe start open source sponsor program to get rights to do such things, like based on need of project you might give them free hosting, free services, free etc... for project owners of smaller projects give them all some small grants. If every company did that for such models we will have much better OSS.
Also still IMO there really doesn't seem to be much we can do against it in the OSS space atleast, all code is open-source is hence code that's all openly readable, if a model is assumed to be a system that doesn't do 1:1 copy, the grounds seem shaky for legal process. Though honestly I very much want to be wrong, can we like file a lawsuit against such AIs in general, I see a similar problem with DallE looking at copyrighted art... What's next copyrighted music? Can't believe I am saying this but I feel bad for people who have copyrights. Music labels, entertainment empires, big services companies(like Accenture) and such will probably somehow survive, but the smaller people will get crushed.
And I say that as someone who primarily pursued Machine Learning in academics until graduation.
Maybe getting some "justified" compensation would be achievable...!?
I'm glad to see that some projects are leading the way in this direction. To me, this move shows that the devs are competent and not afraid of migrations away from legacy forges if necessary; similar to how people moved from Sourceforge to GitHub 10 years ago.
I'll keep Kyoto framework in mind if need an SSR frontend framework in the future! I suggest others do the same.
----------------------------------------
it's public, whatever their investor will ask, they'll comply, github is their competitor, they'll want the same product
unless you self host, in that case it is debatable but for how long
we need more services like sr.ht, and less like github/gitlab
https://en.wikipedia.org/wiki/Idea%E2%80%93expression_distin...
https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari...
At that point the code needs to be GPL licensed, or it's a breach of license. It's plain and simple.
Triviality cause is hard to argue, because you can code a nice "trade secret", or an algorithm worthy of its paper in ~25 lines (at least I did).
So Copilot's use of GPL licensed code is not fair use in my eyes.
BTW, all my public code is (A)GPLv3+ licensed. I want my code to stay open, not closed.
There are many GPL licensed codebases (e.g. Linux Kernel, GNU Octave, GNU R, etc.) which contains serious research and novel ideas and implementations. These codebases are esp. licensed that way to keep that research in the open.
I have such a codebase which I was planning to open source with a GPL3.0 license, but I postponed that plans because of GitHub's Copilot shenanigans.
As I said, the code contains many novel, yet short snippets which are worthy of their own research paper.
Downplaying the research embedded in open codebases is just harmful to the discussion.
Moreover, Copilot doesn't always derive code, but provides the code as-is, reproducing it comment by comment [0], and with a wrong license while at that.
[0]: https://twitter.com/mitsuhiko/status/1410886329924194309
Expressive, non-technical comments in code are most definitely protected by copyright.
Nice.
Well, we're so naive for making clean room development for so long, and writing EULA's with sentences all in caps stating that this is a trade secret and you can't do anything with it.
BTW, I want to reiterate that I'm trying to keep things open, not closed. So I'm not trying to copyright and protect it from being modified. This is what GPL is actually. So, the research is already there, in the form of a paper. You can re-implement that. But, my implementation is under GPLv3. So I'm not copyrighting/patenting the algorithm. It's certain expression I've implemented as a code, and opened under GPL.
As a result, if you derive anything from my implementation, that's GPL too. If you want that algorithm, it's on paper. Go implement that. I don't care.
A lawyer will tell you that reimplementing code you have read, even if you change around the functions and rename the variables, is inviting a lawsuit. A general defense to a copyright lawsuit is to document that you have never viewed the copyrighted work, e.g. by having one person/team document the function of the code and having another person/team implement the function using that documentation (a.k.a. "clean-room reverse-engineering").
In this case, it would be up to the courts, but having a piece of copyrighted code reproduced verbatim in your project without a license is not a good look, and I highly doubt usage of Copilot would be an affirmative defense.
And in Sony v Connectix we get a ruling that even non-clean room implementations are not in violation if there is no way to reverse engineer otherwise.
I don't think that word means what you think it means.
The word "ideological" gets bandied about a lot here as a pejorative drop-in for "things I don't support".
Perhaps we could be a bit less dramatic when considering the plurality of values people hold.
I guess I mean something like: a fixed cluster of ideas that people apply to quickly make good/bad judgments, often accompanied by strong emotions.
Ideology tends to be generic (the same ideology gets applied to lots of things), predictable (a fixed idea lets one know where one stands in a predictable way), emotional (the need to know this is strongest on high-stakes issues), and binary (each ideology organizes itself in opposition to an opposing one).
I use the term in moderation comments because these qualities are bad for HN discussion. The 'fixed' aspect makes discussion predictable, the 'generic' aspect makes it shallow, and the binary/emotional aspect makes it inflammatory. A bad trifecta for curious conversation.
I'm not sure whether predictable, emotional and polar qualities are necessarily intrinsic to "ideologies" in the broad sense. Novel, calmly reasoned and nuanced commentary could be offered in support of positions so labelled. But I get your drift on "touchy topics that people are prone fly off the handle over". FWIW I think this has more to do with stated identity than abstract modes of thought these days. As a moderator I guess one gets a sense of the dynamics of a thread and when it's going to tip in a bad direction.
As I see it, we've come through, and remain in, an interregnum for perhaps 50 years, in which the word has become dirtied by the failures of political and religious practices. And also by incessant and needy "wars" on <the next terrible thing>. A thematic analysis of news from the past 20 years would surely place "ideology" in close proximity to words like "radicalised" or "extremist". That is parochial.
As a sceptic I'm possessed of a meta-ideology - that ideologies in themselves are healthy. We can have ideologies like economics, belief in space-faring exploration, benevolent technological society, self-determination in health and preventative medicine, and other powerful ideas which, in this forum, would be inarguably deemed positive. Perhaps, unless we propose abandoning thought as a way of being (in a Buddhist sense) ideology is just the inescapable waters in which we swim.
I guess what bugs me is if people use "ideology" as a bare, dismissive accusation that attempts to cut-off further dialogue. If everything and anything, including scientific method, can be an "ideology" it ultimately adds nothing to the conversation.
respects
Automating code generation is part of the self-accelerating process of the techno-singularity, eh?
BUT, they're one of, if not _the_ most important technological invention that currently effect us. So, that trumps ideological and legal hurdles, and thus we should use them.... right?
I would like to presume you would disagree with that assertion.
With that in mind, would you like to reconsider your justification for continuing to use GitHub?
To be clear, I'm not arguing that you shouldn't use GitHub. I'm arguing that the importance, or impact, of an invention is irrelevant to its continued use.
What's important is the short, and long term _effect_ of continuing to use it.
> Lots of projects are on other code hosting services.
Yes, and they usually tend to stay there, unless the code hosting service starts doing unusual things with your code. The README of the linked project is quite explicit about all this.
As the guidelines say: "assume good faith".
The discussion on this thread is great but I am not sure that this project is that significant.
This article was pretty eye-opening. https://sfconservancy.org/GiveUpGitHub/
To me, I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS, but when they reel in many paying customers, they can pretty easily, and without consequence, change their policies to be more aggressive (geared towards profit) and greedy. It just seems inevitable to me.
However, decentralized hosting and governance might make it so that there can't be a hostile takeover and incorrect (relative to license) usage of FOSS code. I'm thinking something akin to IPFS but more specialized towards e.g git repository hosting.
Not sure how such hosting would be feasible in terms of breaking even between hosting costs, but a decentralized service hosting distributed VCS databases seems more along the lines of the philosophy of DVCS's in general. DVCS's in general do not have timeliness requirements (i.e your "git push" most of the time doesn't have to propagate worldwide immediately) and the other goodies that come with being on GitHub (e.g CI/CD) seem orthogonal to the actual code hosting itself, and I don't see why that can't be built separately without being part of the service.
But with sourcehut you can just host it yourself or find someone else who hosts that as everything is FOSS.
If you don't want to use the built-in CI, wiki and issue tracker, then Git is already decentralized. You can push and pull easily from and to multiple sources. Git is already built for that exact use case.
Git is a great protocol. You can pull/push to HTTPS servers, SSH servers, even directories (so via NFS if you so wish). Really, Git is really awesome in that way.
But Git itself is not a "code hosting service" that parent asked for. That requires more. Something like Fossil SCM would probably fit better, or git-ssb as I mentioned in another comment here.
You are really comparing DeVault with, of all companies, microsoft?
I'm a bit scared of putting this link here, as the gateway is not super reliable, so I'll ask people who are curious, to get ssb running locally and pull down the data if they want to look into it deeper.
But regardless, here is the link for the curious minds who can't wait, it's the repository for git-ssb itself: https://git.scuttlebot.io/%254Dsh92G6zkkLnR3%2Fys%2Fv42MD0jK...
If you get server errors, jump on ssb yourself, or wait some seconds/minutes and refresh. Be kind to the poor server.
I wouldn’t trust anyone that claimed it, not even myself.
I wasn't paying for it though, or using the account much.
Edit: seems Ethereum is a opt-in optional part of Radicle, so I see how people could believe it to be a part of the whole "Web3" effort.
Well, as long as I can run it without Ethereum, I'm happy.
Cryptocurrencies are just an extra. No wonder, people here hating on Web3 all the time, if they don't understand that.
Web3 is utterly synonymous with cryptocurrency. Plenty of people here understand what it is and what is discussed when the term is brought up.
Your comment was basically "I know better and people who are my opinion know this too".
I'm not that long in the Web3 space, but from what I read I got the impression it's about decentralization, self-sovereign identity and permissionless infrastructure. These are fundamental building blocks, which happen to allow the creation of cryptocurrencies, but, as systems like IPFS or Radicle show, they also allow the creation of different things.
I wasn't taking the high road. It was not necessary nor conducive to good discussion for you to end your comment the way you did.
>Your comment was basically "I know better and people who are my opinion know this too".
No, it was not.
I think, IPFS and Radicle did good here by not making these type of payments mandatory.
They said: if you don't want to run all that stuff yourself, pay someone to host your node. If you want that someone to host nodes in a decentralized matter, you can pay them with crypto.
Moving to Radicle would completely eliminate the issues the maintainers had.
Moving to another provider seems like they just "hoping" for the best.
After 10 years, the thing dies, or grows so big it becomes a corporation, run by suits, hungry for new revenue. There are probably exceptions (HN is one, as it is more of a well kept and groomed "pet" than a business in itself. Meant in a nice way as I love pets).
Death is an interesting one. Reading that Prince's estate is trying to color troll [1], means that regardless of what Prince wanted (not sure what he wanted either way), some other heads with different ethics can take over and do something different from the ethos you thought you were buying into.
This suggests the incentives for YC are more aligned to users’ goals than, say, Reddit.
For a start, the company is bootstrapped and we have no private investors. The revenue to maintain the platform comes directly from users, and all users are expected to pay if they have the means for this reason. We are accountable only to them and we do not have to find "creative" ways to monetize them (or their work) because they are already footing the bill themselves. Every cent paid by users stays in open source, either supporting the platform or the dozens of projects our engineers maintain or contribute to in the FOSS ecosystem.
We also seek to be as transparent as possible. Our financial reports, monitoring system & alarms, security reporting, operational documentation, backups, and so on, is all publicly available. We have hard data that you can use to understand our platform's sustainability, security, performance, uptime, and more.
And, unlike GitHub (and GitLab), SourceHut is 100% bona-fide free software, mostly AGPL. You can run it on your own servers, and we make it easy to import and export your data, in standard, interoperable formats that you can use to move between instances or even between software stacks, such as GNU Mailman or other solutions. SourceHut is also not an ivory tower -- we elevate our users to peers, and many parts of our system are officially maintained by independent volunteers.
I work really hard for our user's trust and I'm proud to know that I have it. If anyone has questions or concerns, I'm always prepared to listen to them and do what it takes to make sure our users are confident in the platform. FOSS is my life's passion and I am committed to doing it right.
To me, this makes it unsuitable as a frontend for community-focused projects that cater to involving and attracting strangers, and much more something for single-committer repos.
Ultimately, building large software ends up being a team sport, and I never got the impression that your product had the express goal of facilitating (and causing) collaboration; in fact quite the opposite: that those are explicitly out of scope for the project.
GitHub is explicitly designed like a social network, and this is a design that we reject. Counting stars and scrolling through feeds is a distraction from getting work done, not to mention an unhealthy relationship to have with your work. Popularity is not a metric we think that people should be optimizing for, or one that can even be effectively measured.
So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done. We make it easy to onboard new collaborators by skipping the account requirement to send patches or file tickets. The UI is simple and accessible for users with any accessibility needs, and free of distractions. Colors are used deliberately to attract your eye to the action items on each page, not to dazzle you with information overload. These are the kinds of motivations which guide the design of the platform.
For the social aspect, we encourage you to branch out. Talk about your project on Hacker News. Maintain a fediverse presence. Put up a marketing page and documentation on SourceHut pages. Cultivate welcoming mailing lists. There are many ways to crack an egg.
What about the case where getting the work done involves doubling the number of people involved in the project, and not a single line of code?
Nobody's on the fediverse, and email is not taken seriously by most modern developers. These interactions still happen on the web.
It’s the only social media I use, and it’s a ghost town. We have to live in the world that is, not the one we wish were.
I used to have a Twitter follower count on my niche little tech/privacy account that is higher than the DAU count of the entire fediverse.
No, it's nothing like Twitter in terms of DAU. However, your Twitter account compared to your Fediverse account is not a good representation of the entire state of the Fediverse. And: it's not necessary to capture 100% of the market share on attention. It's simply necessary to capture enough that your project is successful.
Moreover your mailing list can facilitate discussion, so nothing is lost.
I will likely buy another subscription (and actually use it) at some point in the future but until then I'll be recommending sr.ht to anyone in need of lightweight and open development platform.
Keep up the good work!
https://news.ycombinator.com/item?id=31963630
So I'll reply here instead.
> This is somewhat off topic, but I'm wondering if you've considered offering a pre-paid lifetime plan. sr.ht looks great, and I've considered moving my project over from github, but the thing holding me back is that I don't want the obligation to maintain a subscription into perpetuity. Github's killer feature isn't that it's free, but rather, that I can get hit by a bus (or just become busy with other things in life), and my project will remain hosted indefinitely.
There are currently minimal penalties for non-payment, and in the future, they will remain conservative. We will place your account into a read-only mode after a grace period, but will not remove data without consulting you first. We are people first, free software second, and a business third. We would be honored to set profit aside in the interest of maintaining our users' legacies after they're gone.
In the sense that at the moment I don’t pay for Github and my projects remain there hosted for free.
What would happen in sr.ht jf for whatever event I stopped paying for the service?
It'd suck to end up in a situation like you see with torrents, where there are tons of references, but no access to the data.
I can imagine tons of useful code being lost over time that way.
So the real question is — what are the features of GitHub would you like to see decentralized? CI? Issues? Wikis? Because, you can self host many of these with gitea, GitLab, or sr.ht. That’s the best kind of decentralization, but it does add to your own personal overhead (maintenance, backups), and really limits discovery.
I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.
While keeping the property of very high availability? And making it convenient.
I think the first two steps could be covered by a source search engine that spans different repository providers, and includes self-hosted git instances.
That source search engine will probably be centralized, although if we are just searching names and descriptions (and not code) the engine could be a fairly small .zip file that anyone can install. So comes down to "passing around lists".
But that isn’t helpful for cross-language searching, or a code search engine (which I think is a great idea).
- Issues.
- CI.
- "Home page" with the readme.md rendered.
Easy discoverability is a large concern. Easy discussion with fast round-trips and a trail is important (email or NNTP can help here though). CI is a thing that may need a serious effort to get running smoothly.
These things are centralized because it's easy to implement them once in one place instead of reinventing. But if there'd be an obvious and bullet-proof way to have them replicated (like in Fossil), the need for strict centralization would wane.
Discoverability would still be an issue though. It's like torrents: completely decentralied, but without a directory like TPB it's really hard to find them.
Sourcehut itself is fully federated if you are willing to learn email workflow. You don't need to register an account anywhere to collaborate on sourcehut. That include feature requests, bug reports, discussions, submitting patches and even pull requests from any public repository anywhere [1]. The discussions also exist on mailing list archives and personal mailboxes. They are not lost even if you decide to change host.
But developers are extremely resistant to email workflows. When I suggest it, people react as if I am suggesting black magic. But in my experience, email workflow isn't that unpleasant. Most of the problems with email workflow are due to poor email clients (issues with plain text, composing, rendering and threaded displays). Setting up git and a good but simple email client for git is not a hard task. The rest of the workflow is actually very pleasant.
Why?
I wrote this article about decentralized forging and the different approaches to it, P2P and federated. It's not exactly an in-depth analysis but i believe it's a good high-level overview of the ecosystem which has changed little since then.
Give up GitHub: The time has come - https://news.ycombinator.com/item?id=31932250 - June 2022 (544 comments)
GitHub is already niche for the general populace, most people haven’t heard of it. Among programmers, alternative SCM platforms outside of GitLab and Perforce are niche. When we multiply the two together we get an incredibly small set of potential users (and the UX challenges of ActivityPub are still there).
Also, for what it's worth, I quite enjoy my self-hosted Mastodon account and long since stopped using Twitter and Facebook.
Usually I find at least one or two new things that are interesting.
Why was Sourcehut chosen? Any specific appealing features?
Any alternatives considered?
SourceHut's fees are very cheap ($2/mo) and users who cannot pay for any reason are offered free service.
If you will only use services that you don't need to pay for, that's your choice, but you should respect the choices of others who consider these incentives and their outcomes more important.
I agree with you that the world where open source code is not hosted by private companies is a better one. However if our plan is to rely on the already-insufficiently-supported/rewarded maintainers changing their workflow, changing tools, and paying their own money (however low), we won't get there.
Just like I think a world where all important software is open source is a better one. To get there, we just need corporations to give maintainers some of their own money. We are not getting there.
SourceHut is a corporation that donates to FOSS projects, by the way. We sponsor many projects and we're planning on building more tools to get maintainers paid for their work.
A call for action is all the more effective if that action is easy. The Software Freedom Conservancy's call has a lot of background but if the proposed action is "host it yourself" or "pay money for SourceHut", I worry that we will not move forward.
If you feel differently, perhaps Codeberg is for you instead? SFC recommends them as well and I am just as happy to see projects move there as I am to see them on SourceHut -- we're a paying (but non-voting) member of Codeberg ourselves. Diversity is healthy for the ecosystem, but the proprietary platforms ought to be expelled.
https://codeberg.org/ddevault/pages
We started paying as soon as we started relying on them for this purpose. We pay one euro short of the minimum contribution for voting rights, to support them while respecting their independence. Codeberg is doing wonderful work that we (and the community at large) are depending on and we're prepared to support that without hesitation. Diversity is good for FOSS.
how are they different, or better, than any other floss instance (disroot, framagit, gitgud, savannah, NotABug, pagure, etc)?
I totally agree with you! This is why I think we will not be moving forward, with things as they are.
On the contrary, it means only people that really want to be on Sourcehut will do so.
Which is probably for the best, certainly while it’s still in an alpha state.
Slow and steady wins the race.
Only having a few committed users join SourceHut is great for SourceHut. Having only a few committed users leave GitHub is not great for GiveUpGitHub.
The project points to [0] as its rationale for leaving Github. One of that document's complaints about Github is that they do business with the US's ICE department. It's not the only group from which I've heard such thorough contempt for ICE.
I understand why people might have problems with some aspects of ICE's activities, e.g. charges of inhumane treatment of people crossing the border without authorization. So it makes sense to me that they'd protest those particular behaviors.
But protesting all of ICE makes no more sense to me than un-nuanced calls to entirely defund the police, or abolish the entire DoD. I.e., it seems obvious that totally eliminating any of those government functions would cause problems that almost nobody would find acceptable.
Is there something I'm missing?
> If you're using version 0.x, please, make a fork, or create a local project copy.
I feel like an official mirror on GitHub would be cleaner, as the old URLs could still work, but I suppose that doesn't match the vision.
SourceHut is missing a lot of features from GitHub, I'm not even sure if SourceHut has a file tree. It's interface is also much different than GitHub's.
Meanwhile GitLab is almost an exact clone of GitHub. It has discussion boards, pull requests ("merge requests"), even CI which replaces GitHub actions.
I figure SourceHut is more FOSS-friendly than GitLab. But GitLab still supports self-hosting, and AFAIK is open-source and FOSS-freindly itself. The KDE and GNOME project even have their own hosted GitLab versions. All-in-all I just think migrating from GitHub to GitLab seems much easier than migrating to SourceHut.
On the other hand, sourcehut promotes better workflows, in favor of a really snappy web interface.
For those who are attached to forks and PRs there's also a web UI for submitting a "patch set" which basically walks you through the process the same way as a pull request.
There are projects like linux that don't accept PRs on github and swear on sending patches. Obligatory Linus Rant: https://github.com/torvalds/linux/pull/17#issuecomment-56546...
What makes using email or certain technologies uncomfortable, but using a new language or framework comfortable?
> (and I include myself)
The link with the associated comment threads we are paticipating in could have easily been an email and every comment could have been a direct reply to that email or a reply to one of the comments. Would that be more or less comfortable compared to just having this discussion on the web interface on https://news.ycombinator.com?
The only difference is that you could have to click on each comment to read the body of the message, but the tree structure would be the same as it is now.
But your comment doesn't answer my original question about level of comfort. Why is learning how to write programs, run them, and learn frameworks considered a comfortable activity, but using email is not? The former is orders of magnitude more difficult compared to the latter, so ease of use doesn't seem to be the reason.
And they all died out quickly as soon as web-based platforms stole their audience.
In my experience, any Microsoft Exchange/O365 server will most likely mangle the email server side (introducing quoted-printable encoding characters or changing the message-id field. Gmail will require that you enable insecure application access in order to use git-send-email. If you don't do that, then using git-send-email will result in a authentication failure error (which you can see if you use the --debug flag).
So this email-only workflow doesn't work with the two most popular email clients. Where do I sign up?
Clearly you don't understand the difference between a MUA and a MTA. Perhaps you should spend some time learning the difference instead of engaging in any more name calling. There's no use continuing this discussion when you outed yourself as someone who has no idea what they're talking about.
> I don't know much about it, but I'm going to dig into it in the near future (https://man.sr.ht/lists.sr.ht/). For now, those who want to contribute, I'll just add read/write permissions to the project.
I have no idea what is kyoto and if it fits there.
I'm not asserting that as an argument for email, or PRs, but rather just that I'm certain there's people who feel, and are, extremely productive in vim, or collaborating over email, or programming in PHP, or whatever tech the younger people in the industry would claim is Yikes or Big Oof.
Unless we're talking about Bitbucket. No one is productive in Bitbucket.
if you want viable alternatives to github, pay up!
sr.ht is a nice service that allows some premium features like ssh'ing into ci instances to check failures...there is plenty worth paying for
You can read about the 2021 financials here; it seems that the project is pretty successful overall: https://sourcehut.org/blog/2022-04-08-2021-financial-report/
(Again, to be clear I'm just playing devil's advocate with the semantics. I personally don't believe that sr.ht is doing anything nefarious.)
This is not a guarantee until it is challenged in court or audited by some trusted auditor.
>This take also seems especially outlandish considering that the context is comparing SourceHut to GitHub, which is very clearly more proprietary even in this awkward sense.
No disagreement there.