Yannick Schutzâ forked project aims to help you find maintained forks of your favorite GitHub repos. You enter the GitHub user/repo and it shows all the forks with sortable metrics such as stars, last updated, and open issues.
Hereâs an example result set for the popular-yet-abandoned GitX app.
Ever since AWS took Elasticsearch and decided to sell a managed version of it there has been controversy around AWS and Elasticsearch. Now that the software created by Elastic is being switched to the Server-Side Public License
(SSPL), which is not a very permissive license, AWS is going ahead and forking the projects.
The debate rages around this. Few people feel sympathy with the behemoth that is AWS, but they donât seem to be in violation of any licenses. Elastic have definitely worked hard on Elasticsearch and arguably deserves an opportunity to profit from their work. This new license raises significant concern though.
I donât think weâll see this settle anytime soon, just like the issue of open source sustainability is neither easy nor straightforward.
A popular open source iOS authenticator app goes rogue under new ownership, Andreas Kling steps back from SerenityOS & forks Ladybird, Vhyrro takes a thought-provoking try at a âstatic effect systemâ, Matt Bessey is over GraphQL & Marc-Andre Giroux still likes GraphQL sometimes (in the right context).
Redisâ re-licensing prompts forks like Drew DeVaultâs Redict, Matthew Miller thinks we need more community built software, Paul Gross makes the case that DuckDB is the new jq, Anton Zhiyanov shares how he makes a living as a developer despite being âpretty dumbâ & Baldur Bjarnason chimes in on the state of the web developer job market.
This week weâre talking about the recent falling out between Elastic and AWS around the relicensing of Elasticsearch and Kibana. Like many in the community, we have been watching this very closely.
Hereâs the tldr for context. On January 21st, Elastic posted a blog post sharing their concerns with Amazon/AWS misleading and confusing the community, saying âThey have been doing things that we think are just NOT OK since 2015 and it has only gotten worse.â This lead them to relicense Elasticsearch and Kibana with a dual license, a proprietary license and the Sever Side Public License (SSPL). AWS responded two days later stating that they are âstepping up for a truly open source Elasticsearch,â and shared their plans to create and maintain forks of Elasticsearch and Kibana based on the latest ALv2-licensed codebases.
Thereâs a ton of detail and nuance beneath the surface, so we invited a handful of folks on the show to share their perspective. On todayâs show youâll hear from: Adam Jacob (co-founder and board member of Chef), Heather Meeker (open-source lawyer and the author of the SSPL license), Manish Jain (founder and CTO at Dgraph Labs), Paul Dix (co-founder and CTO at InfluxDB), VM (Vicky) Brasseur (open source & free software business strategist), and Markus Stenqvist (everyday web dev from Sweden).
Kevin Xu:
There are plenty of metrics you can trackâstars, forks, pull requests (PRs), merge requests (MRs), contributor counts, etc.âbut more data doesnât necessarily mean clearer insights. Iâve previously shared my skepticism about the value of these surface-level metrics, especially when assessing an open source projectâs health and sustainability.
In this article, I propose two second-order metrics to track, measure, and continually optimize to build a strong, self-sustaining open source community
Those two metrics? Breakdowns of code reviewers and leaderboards of different community interactions. (He also explains why. Worth a read.)
Track and vizualize your followers/notifications, your repoâs stars/forks/watchers/commits, issue states/assignees/labels, and more.
Phil Nash shared this helpful flow to keep your forks up to date. Most folks can get by with branch, checkout, add, commit, pull and push, butâŚ
âŚwhat if you want to fork and contribute to an open source project on GitHub, GitLab or BitBucket? Youâre going to need a few more commands so that you can keep your fork up to date, namely remote, fetch and merge. Letâs see how they are usedâŚ
Our friends at Tidelift have joined data from GitHub and their own Libraries.io, âthe largest open source software dataset in the world,â â which covers over 2.8 million open source projects. They were able to combine the two datasets to gather the entire commit history of each project on GitHub to more closely examine the following questions:
- What exactly has been Microsoftâs role in the open source community?
- In which projects and ecosystems have they contributed most?
- Have those contributions been focused on the large Microsoft open source initiatives, or has the company also participated in projects beyond their immediate purview?
They were also careful to clean the dataset of forks and duplicate packages which would misinform this analysis.
So whatâs the verdict? Microsoft may have a mixed history with open source, but today the company is demonstrating some impressive traction when it comes to open source community contributions. If we are to judge the company on its recent actions, the data shows what Satya Nadella said in his announcement about Microsoft being âall in on open sourceâ is more than just words.
With so much open source software getting created every day, itâs amazing how much we all benefit from the work of others in the community. But even free software, both as in beer and speech, isnât all unicorns and rainbows. So what do you do when you have problems with that shiny new set of bits? Hereâs a few items to consider.
Most software projects have a mailing list. Google Groups seems to be the most popular, but Librelist is good, too. Before you post your question, check the archives. Perhaps someone has already asked and gotten an answer.
IRC seems to fly below the radar of a lot of developers I meet, but itâs a whole universe of project-focused real-time communities where you can ask questions and get answers. Find an IRC client and join the conversation. You can usually find me in #redis, #github, #mongodb, and, of course, #thechangelog.
There is a difference between a bug and a feature, and surprisingly a lot of folks donât know the difference. Wikipedia defines a bug thusly
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
Whereas a feature is
A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).
The takeaway is that youâll get a lot warmer reception from the project community in most cases if you report an issue and ask for help determining if itâs truly a bug, by design, or a great idea for a new feature.
The term ânasty bugâ seems to be used so much that we wonder if there are any other kinds of bugs. Nasty has become at best trite and at worst loaded. When reporting an issue and its severity take into account actual damage caused by a software flaw and donât inject your own feelings of frustration or inconvenience.
Most of the time, software authors want to help you with your issue but when you drop into the chat room or mailing list with something like âIâm getting errors, any ideas?â, thatâs not actionable information. Hereâs some information you should include:
One of the most convincing ways you can communicate an actual bug is by submitting a failing test. As a gem author, I love it when someone forks the project and provides a failing test for an issue theyâve found. It is the clearest, most concise way to express expected and actual behavior.
If you can write a failing test for your issue and youâre familiar enough with the code to fix it, please go the last mile and submit a patch, preferably on a topic branch. GitHub makes this too easy.
Twitter has encouraged the #lazyweb. Itâs so easy just to include a couple of well played hashtags and fire off a call for help to the Twitterverse. But please donât stalk @gruber with Markdown questions or @mxcl with Homebrew questions that are probably already answered in the wiki.
One of the quickest ways to get support is to pay for it. I know, I know, crazy, right? Appcelerator is an example of a company that gives away their tools and has a booming community around it, but also provides professional paid support for their platform. Opscode is another example, providing supported, hosted deployments of Chef.
Perhaps most importantly, even when youâre frustrated with some bit of open source, show some appreciation. Itâs easy to lose site of the fact that it wasnât your blood, sweat, and tears that went into that code you didnât have to write. A thankful attitude will go a long way in getting help from the author or community
What are some tips you could pass along to the community on how to get (and give) support for open source software?
[button href=âhttp://news.ycombinator.com/item?id=2190097â]Discuss this on Hacker News[/button]
With a name reminiscent of Ego, the at-a-glance traffic/followers/subscribers checker for iPad and iPhone, comes vain, the GitHub followers/watchers/forks checker for the command line from John Crepezzi.
Vain is distributed as a Ruby gem:
gem install vain
You can then get the skinny on any GitHub user with vain <username>. Normally we include example terminal output in a <code> block on this blog, but since vain has such great terminal color support, a screenshot is in order:
You might know John from his excellent ice_cube gem, an amazing recurring date library for Ruby that supports iCal, YAML, and English.
As much as I love the new GitHub pull requests, I like to stay in the terminal as much as possible. When Iâm ready to start patching, hopping between the browser and the command line cuts into productivity.
I was excited to find git-pulls, a nifty command line interface to GitHub pull requests from Scott Chacon.
To get started, install git-pulls via Rubygems:
gem install git-pulls
⌠and update the list of outstanding pull requests:
linkedin [ master: â ] Âť git pulls update ~/Projects/linkedin
Updating pengwynn/linkedin
Checking for forks in need of fetching
fetching camilleroux/linkedin
Open Pull Requests for pengwynn/linkedin
30 01/22 0 Share API sabril:master
28 01/14 0 Support for Profile Recommendations Erol:master
26 12/09 0 add 'notes' field to Education camilleroux:master
23 11/17 0 Get more data from linkedin and bun finalist:master
22 10/29 0 Upgrade to 0.4.0 of oauth. zenom:master
21 10/19 0 Related connections ryanbrunner:related-
20 10/19 1 Two new topic branches with new fie ryanbrunner:recommen
16 09/03 0 bundler and load path madness fix, joshk:master
15 09/02 0 Added field public_profile_url troysteinbauer:maste
linkedin [ master: â ] Âť ~/Projects/linkedin
Whoa. Someone has some patching to do.
To view summary info for a pull request, use git pulls show
linkedin [ master: â ] Âť git pulls show 30 ~/Projects/linkedin
Number : 30
Label : sabril:master
Created : Sat Jan 22 12:03:23 -0600 2011
Votes : 0
Comments : 0
Title : Share API
Body :
add share function for new share API
http://developer.linkedin.com/docs/DOC-1212
Usage:
<pre>
<code>
client.share(:comment => 'new share API', :title => 'Linkedin Share API', :url => 'http://developer.linkedin.com/docs/DOC-1212', :image_url => 'http://images.bizjournals.com/travel/cityscapes/thumbs/sm_sanfrancisco.jpg')
</code>
</pre>
Working on Resharing and Retrieving Share Info
------------
cmd: git diff HEAD...5772b1ee444e6f438ecc01c415236198e0783e00
lib/linked_in/client.rb | 22 +++++++++++++++++++++-
test/client_test.rb | 4 ++++
test/fixtures/shares.xml | 12 ++++++++++++
3 files changed, 37 insertions(+), 1 deletions(-)
You can also view the full details with git pulls show <id> âfull. Thereâs also support for merging pull requests with git pull merge. If you need to comment on the pull request on the web site, you can open the the request online with git pulls browse <id>.
Source control systems like Git make it easier to maintain project momentum and avoid abandoned open source projects. Instead of waiting on project owners to make changes, project users can simply create their own forks and supply their own patches. But this creates other issues over time such as whatâs the canonical repository for the project? Wouldnât it be better if project owners could recruit someone to take the reins and keep the project moving?
Itâs in that spirit that Jeff Kreeftmeijer has created Still Maintained?. Simply log in via GitHub OAuth and flag each of your projects as actively maintained, seeking a new owner, or abandoned.
By the way, Iâm looking for someone to take over my LinkedIn Ruby wrapper. Apply within.
Spree, the leading Rails storefront project, has released version 0.10.0 with some big new changes:
The docs have also been refreshed to cover the new enhancements. If youâre new to Spree, take a test drive. If you need a more custom storefront, you can join the ranks of 300+ forks on the Hub.
Open Source has its own Circle of Life. As we discussed in Episode 0.1.1, Open Source creates opportunities for entrepreneurs. Sometimes those businesses can spin off their own projects, paving the way for the next round of startups.
Sometimes commercial apps just donât survive, but letâs not confuse viable with valuable. Take the case of Storytlr, a hosted lifestreaming service which sought to let you remix your social networking interactions into your own âstories.â When the hard decision was made to pull the plug on the service at the end of last year, the founders did what many apps have done and handed the source code over to the community.
The official Storytlr open source project is on Google Code but John Hobbs has a fork on GitHub that adds:
For a live demo, check out @abrahamâs Storytlr at http://stream.abrah.am/.
Storytlr runs on PHP (which runs darn near everywhere) and installation instructions can be found in the README.
Derek Collison â creator of NATS and Co-founder & CEO of Synadia â joins the show to dive into the origins, design, and evolution of NATS, a high-performance, open-source messaging system built for modern cloud-native systems and part of the CNCF. Derek shares the story behind NATS, what makes it unique, and unpacks the recent tensions between Synadia and the CNCF over the future of the project.
Matched from the episode's transcript đ
Derek Collison: Yeah, youâre absolutely right, and what weâve heard from the ecosystem is we like that model because thatâs whatâs familiar to us. What I try to point out to people is that commercial forks - itâs totally up to Synadia, and maybe thatâs totally fine, and people are saying itâs fine, but again, I donât think folks think all the way through some of these things sometimes⌠Itâs at our discretion what we put in there, and itâs also our discretion that we donât have any commitment to put it back into the open source community whatsoever.
[01:20:05.08] So letâs say thereâs something, Jerod, that you really, really wanted, and youâre an avid user and stuff, and Synadia decides âOh, weâre only going to put it in the enterprise version.â Youâre stuck. Now, of course, you could try to do your own version of it in the OSS side⌠But at the time - and again, this was in a vacuum, and [unintelligible 01:20:20.02] additional information, but I was arguing hard that the BSL would signal a better commitment to saying âEverything will become AP2 after two years. No matter what we put in there, it will become that way.â
Nathan Sobo is back talking about the next big thing for Zedâagentic editing! You now have a full-blown AI-native editor to play with. Collaborate with agents at 120fps in a natively multiplayer IDE.
Matched from the episode's transcript đ
Jerod Santo: Thatâs just why when I was like âThese cool, new agentic things and theyâre all VS Code forks.â Itâs like, Iâm sorry, I just donât enjoy VS Code. Thatâs just me personally. I feel like itâs coach; that Iâm flying coach. So thatâs just me giving Zed more props.
Beyang Liu, the CTO & Co-founder of Sourcegraph is back on the pod. Adam and Beyang go deep on the idea of âindustrializing software developmentâ using AI agents, using AI in general, using code generation. So much is happening in and around AI and Sourcegraph continues to innovate again and again. From their editor assistant called Cody, to Code Search, to AI agents, to Batch Changes, theyâre really helping software teams to industrialize the process, the inner and the outer loop, of being a software developer on high performance teams with large codebases.
Matched from the episode's transcript đ
Beyang Liu: Yeah. And look, heâs awesome. Look, I love the Zed folks, too. Weâve had one of them on our podcast back in the day; I really love what theyâre doing. I think itâs a fantastic editor, and I sincerely hope that it becomes really big. I think they have a unique approach here. Theyâre not a VS Code fork. Theyâre really kind of rebuilding an editor up from first principles, and focusing very much on performance, which I absolutely love to see as a developer. And I hope they succeed. I would love that to be an editor that I could use someday.
As far as our business is concerned, the way we view the in-editor experience is â maybe this is a difference in our vision for the world compared to some of the other players in the space, but we donât think that thereâs going to be a single code editor that is universally adopted for every language and every platform in the future, much less a closed-source one. I think open source in the editor remains important, because itâs so near and dear to the inner loop and the individual developer workflow.
So when we think about the type of in-editor coding experience that we want to enable, we start from a point of wanting to deliver that experience into the best editor for your particular ecosystem or your platform. I guess thatâs somewhat of a contrarian view these days, because thereâs all these VS Code forks floating about, that frankly speaking theyâve done a really good job on some of the core UX, and kind of pushed the frontier in terms of showing people whatâs possible with AI. But the long story â I guess the short of it is for us, we are thinking about building for the large codebases that make the software that power the world. Those are multi-editor environments. Theyâre also environments where itâs not just the context inside your editor that matters, itâs actually connecting it back to the overall context of your organization and the entire codebase. So the way weâre approaching about building for the editor is to bring the best AI UX in the field in a way that feels native to each of the editors that we support. We eventually hope to support all the editors out there.
Antirez has returned to Redis! Yes, Salvatore Sanfilippo (aka Antirez), the creator of Redis has returned to Redis and he joined us to share the backstory on Redis, whatâs going on with the tech and the company, the possible (likely) move back to open source via the AGPL license, the new possibilities of AI and vector embeddings in Redis, and some good âol LLM inference discussions.
Matched from the episode's transcript đ
Jerod Santo: Thatâs really interesting. So â and youâre happy about that, because now you have basically⌠Like, Redis gets pushed forward, but also Valkey gets pushed forward in different directions, and different things work for different people, in different circumstances, so itâs kind of spurring some innovation. Did you see Redka? Is that one that crossed your radar? Because thereâs a bunch of forks that came out back when Redis was first announced that the license changed. Redka was not a fork, it was like a re-implementation. Are you familiar with this one, Salvatore?
Preston Doster joins the show to tell us what it takes to run a Mastodon server with 55,000 accounts and 11,000 monthly active users.
Matched from the episode's transcript đ
Justin Garrison: So how has that â youâre using the official Mastodon instance, right? Because there are forks, there are other options. I used one for a little while that Cloudflare wrote, Wildebeest, which was all integrated into their workers, and stuff like that⌠And I thought it was really cool, because it was like a âserverlessâ Mastodon, but it was like extremely difficult to upgrade and to change things. But youâre using the official Mastodon software, which is a Ruby on Rails app, with like a Postgres database, right?
(Includes expletives) David Heinemeier Hansson (DHH), creator of Ruby on Rails and co-owner of 37signals, joined the show to discuss this Rails moment and renewed excitement for Rails. We discuss hard opinions, developers being cooked too long in the JavaScript soup, finding developer joy, the pros and cons of the BDFL, the ongoing WordPress drama with WP Engine, and whatâs to come in Rails 8.
Matched from the episode's transcript đ
David Heinemeier Hansson: Hereâs an example of you went from BDFL to committee style, but on a very different premise, and I have no interest in Redis at this point forward. I think itâs an amazing piece of software, I loved it for many years⌠If Iâm starting a new project tomorrow, Iâm starting it with Valkey, or any one of the other forks. Iâm not going down that dark path.
So things donât last forever. And I think we can delude ourselves into thinking that because we have such a young industry. Do you think architects think âOh, this building is going to last foreverâ? No, because theyâve seen literally the history of civilization. Build things, destroy things. Build things, destroy things. Or things just falling apart.
[01:29:50.13] Weâve been around, in our modern inclination for - what, 50 years? 60 at the most? Well, everything is still here. COBOL is still here. Fortran is still here. You can actually still compile and run those programs. Weâve not yet seen proper destruction. Weâve seen some degree of abandonment, maybe⌠But we donât have the timeline to really appreciate these things on. And therefore, we are liable to delusion that things are going to last forever. Theyâre not.
Jerod & the gang play âTwentyâ Questions to get to know Amy, review the big Svelte 5 release, discuss commercial open source & get Nickâs report from SquiggleConf!
Matched from the episode's transcript đ
Jerod Santo: I think thereâs a slight category difference between Svelte and Next, because one was brought in and the other one was developed on behalf of, or started inside Vercel, for that purpose, surely⌠Which was, I thought, brilliant marketing by the Vercel team. I mean, itâs worked very well to have Next.js, and have it tied so tightly to the Vercel things.
The thing about open source is that thereâs always the fork button, and nothing lasts forever. I mean, ZURB Foundation was amazing, it brought a lot of value to a lot of people, it helped ZURB out for a while, and then when it stopped being valuable, fell behind, obviously. Not great, getting let go, and having to find another job, and like all this stuff. But the good times were good, and sometimes things just come and go, and they move the industry forward⌠But not everything sustains forever.
I mean, WordPress has been a shining star in both open source and in venture, or I should say maybe in business, I donât know about in venture. And so thatâs why its fall has been so dramatic. And because, like you said, Amy, such a large percentage of the internet is using WordPress⌠WordPress as a brand I think, is going down. As a piece of software, itâs going to continue for decades. Maybe itâll lose some of its usage, something else might come along thatâs better, and definitely Matt has sown discontinuity and uncertainty into that community, which is never good⌠But if itâs bringing value, someoneâs going to pick it up and run with it. And whether itâs AnyPress, or ClassicPress, or - thereâs a few different forks attempting. Or just WordPress, making it through this hard time. When you have that level of usage, your death is slow, and more that you become like culturally less relevant, but still there.
From switching ISPs to migrating Amazon off Oracle, Pete Naylor knows which database to use.
Matched from the episode's transcript đ
Justin Garrison: [00:54:09.24] I think your point also on like compatibility, API compatibility, with âOh yeah, weâre wire-compatible with that other databaseâ causes so much extra confusion. Because youâre like âOh, should I use it like that other database?â And like âActually, no. Not at all. But you can send us the same data.â That causes so much more just forks of âWhat are you actually good for?â
Will Crichton wishes some naming conventions would die already, GitHub user brjsp noticed that Bitwardenâs new SDK dependency isnât open source, Joaquim Rocha details his forking best practices, Sophie Koonin explains why you should go to conferences & Mike Hoye puts WordPress on SQLite.
Matched from the episode's transcript đ
Jerod Santo: Forking best practices
Joaquim Rocha:
Fork maintenance â keeping your changes in sync with the latest updates from the original project â can quickly become a mess. Trust me. Over the years, my work did sometimes involve maintaining forks of various open source projects. Thatâs not the case with my job now, but when a colleague reached out for help with a fork that hadnât been rebased in ages, it got me thinking that the steps I follow might be useful for other developers too. Hence this article.
This is an excellent guide for what can be a tricky (a.k.a. frustrating) task. Before Joaquim gets into the rebasing/merging section, he kicks off with some great day-to-day development tips, such as:
Side note: we shouldnât need all these guides! Thereâs a lot of value (a.k.a. money) to be made by anyone who makes the entire code collaboration process an order of magnitude easierâŚ
Jerod is joined by the co-hosts of core.py , Pablo Galindo & Ĺukasz Langa, a podcast about Python internals by people who work on Python internals. Python 3.13 is right around the corner, which means the Global Interpeter Lock (GIL) is now experimentally optional! This is a huge deal as Python is finally free-threaded. Thereâs more to discuss, of course, so we get into all the gory details.
Matched from the episode's transcript đ
Ĺukasz Langa: Right. So the JIT is still one of those other topics that I remember being this big pipe dream of CPython for as long as I can remember. We grew a few attempts to have a JIT in forks of Python, or entirely new Python interpreters⌠Most of those efforts failed. Thereâs one holdout that is actually doing very well, thatâs PyPy, and that is actually JITed, which proves that this language can successfully use this performance strategy for good results.
Joseph Jacks (JJ) is back! We discuss the latest in COSS funding, his thesis for investing in commercial open source companies, the various rug pulls happening out there in open source licensing, and Zuck/Metaâs generosity releasing Llama 3.1 as âopen source.â
Matched from the episode's transcript đ
Joseph Jacks: Iâve created a hugely successful project⌠Wow. Amazing. Guess what? Hereâs what Iâm willing to do, hereâs what I am doing, and hereâs what you should expect of me in the future. Anything that deviates from that, I will not respond. That is completely not only reasonable, but very admirable. And those people should be celebrated. There are so few of them. So few of them. And instead, what people do is they mistake and misunderstand, partially because I think of a lot of weird, twisted framings that Richard Stallman actually proposed early on, because he had a much more ideological view of this, which I think is not helpfulâŚ
In a pragmatic sense, when you create an open source technology, you are opting into creating a permissionless innovation thing of some kind. And you shouldnât feel obligated to the world of your users and your people impacted by your technology that you should work for them and do anything for them. And in that type of world, there would be fewer instances of burnout, frustration, pain, suffering on the part of open source maintainers. And so for us, investing in open source companies is a way of creating a capitalist system and structure around sustaining an open source community, while also creating a business model for it, which expands the universe for open source and creates the right incentive system. But what it also does is it says âLook, you should be really, really good at setting expectations, maintainer⌠Because youâre going to work with a professional investor who also has other investors invest alongside after that fund.â Many of the best investors in the world, in fact. âThose people will help you and advise you.â And as an open source maintainer, learning how to create a company gives you the skills of learning how to create and set expectations for many complex stakeholders, employees, customers, and investors, to name a few, that you didnât have before, and it gives you the ability to get really good at setting boundaries on what you are willing to do, what you will do, and what you are actively doing to the people that support you.
And if you translate that, and you kind of reverse that into the way you run open source communities and projects, the world would be so much more efficient. I think a lot of forks happen because people are like âLook, I disagree with the maintainerâ or âTheyâre not doing this thing, or not doing that thing.â Those things wouldnât have happened if you said âLook, you can always fork the project. Thatâs the fundamental of open source. But this is why Iâm doing what Iâm doing, and this is kind of the expectation you should have.â So I think expectation setting is really fundamental and super-critical for people to kind of learn. Itâs hard. Itâs a very difficult skill to learn, but itâs very, very important.
The Switzerland federal government requires releasing its software as open source, Google decides not to deprecate third-party cookies, Mark Zuckerberg says âopen sourceâ AI is the path forward, GitHub allows anyone access to deleted / private repository data & Tailscale wants to build a New Internet.
Matched from the episode's transcript đ
Jerod Santo: Anyone can access deleted and private repository data on GitHub
This sounds⌠not ideal
You can access data from deleted forks, deleted repositories and even private repositories on GitHub. And it is available forever. This is known by GitHub, and intentionally designed that way.
Theyâre calling it Cross Fork Object Reference (CFOR). It occurs when one repository fork can access sensitive data from another fork, even if said fork is private or has been deleted. The how is detailed in the linked post, but the most interesting / concerning thing is that itâs not a bug, itâs a feature? After notifying GitHub, they replied:
Thanks for the submission! This is an intentional design decision and is working as expected as noted in our documentation. We may make this functionality more strict in the future, but donât have anything to announce right now.
Perhaps a good takeaway of this is: donât use private forks (just in case) q q
Devyn Cairns & Jakub ŽådnĂk join Justin & Autumn to talk about building a new kind of cross-platform shell that provides easy extensions with traditional command compatibility. Thatâs no easy feat!
Matched from the episode's transcript đ
Autumn Nash: These operating systems belong in the same class as Linux in that they are UNIX ideals and APIs. DragonFly is a fork path, so to speak, giving DBS base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD 5. This is like medieval times when all the different churches started, because people started fighting⌠And then when the open source community start fighting, theyâre like deuces. âWeâre gonna go create our own forks.â And then you end up with like five forks of the same thing.
In this weekâs episode weâre talking about the news! In this laugh-filled episode, Kris is joined by Ian & Johnny to discuss the future of Go, both the Go team itself and iterations of packages within the standard library; Microsoft creating a Go blog & a Go fork; and SQLite and Go.
Matched from the episode's transcript đ
Kris Brandow: We got so off track⌠So I donât know, what are your thoughts about all of these new forks and things of Redis? Or this one in particular, ofâŚ
First there was Mamba⌠now there is Jamba from AI21. This is a model that combines the best non-transformer goodness of Mamba with good âol attention layers. This results in a highly performant and efficient model that AI21 has open sourced! We hear all about it (along with a variety of other LLM things) from AI21âs co-founder Yoav.
Matched from the episode's transcript đ
Yoav Shoham: Yeah, it really was very simple. We felt like if we were the only ones augmenting and pushing out this model, it wouldnât advance as fast as it could. And we saw that within days of our putting it out there there was⌠I think today â I havenât tracked it, but when I looked at it about a week ago, there were 30,000 downloads, and I forget how many forks, but a large number of forks.
So either way, very important to say what we put out is a base model, not a fine-tuned model. And we were very clear about it, and we cautioned people for using it for production purposes, or for a user-facing application. And of course, weâll be coming up with our â in fact, weâve announced that itâs available for preview, our aligned model. But we felt like it was really important for the community to add value to this architecture, and thatâs why we did it.
