mickael-kerjean

> France is not adopting existing open source software

As a Frenchman, this stings. I have been working since 2017 in creating an open source alternative to Dropbox (https://github.com/mickael-kerjean/filestash), the reality is out of 60 customers, only 2 are French and most contacts I've had with French entities only shown interest onto open source because they were not willing to spend a dime on anything.

Customers are mostly US entities and other countries in Europe. The gist is our technology is already working accross every possible storage technology and every identity provider, has a clean modern UI, has gateway capabilities to expose your data with open protocols like SFTP, FTP, S3, MCP, with virtual filesystem capabilities that enables a decentralized approach through federation and tons of other advanced setup, is deployed in production in places like US military, MIT, European Commission and many other othher high profile places.

We just launched https://www.filestash.eu a few days ago hoping to talk to people in France who are interested in translating the talk of data sovereignty onto actual actions. If anybody who is reading this is truly interested onto a sovereign Dropbox and is willing to put talks onto a concrete reality, reach out to me, I'd love to talk to you

As a Frenchman involved in creating an open source Dropbox (https://github.com/mickael-kerjean/filestash) that can connect to any kind of storage and can expose itself as not only a web client but also SFTP, webdav and S3, with virtual filesystem capabilities and tons of other cool stuff, out of 60 customers, only 2 are French, the only people I see coming from France are only ever interested in open source because they don't want to pay anything (other countries in Europe are different though)

If anyone involved in this transition read this, please contact us, we already got open source technology to replace box / Dropbox / OneDrive and Gdrive

> It started out relatively simple and easy to understand ....

when the specs for a data representation format evolved with XML bombs abilities, it has gone too far in trying to please everyone, and that is probably why JSON won in the long run, it's not perfect but stable and simple without crazy issues you have to worry about when parsing it. If XML had a Torvaldish kind of dictator who can afford to say no, I doubt JSON would have won

I use it extensively in my OSS work (https://github.com/mickael-kerjean/filestash) mostly around:

1. creating plugins that get executed in the browser to render files like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, GIS related files and many more, where C libraries are almost always the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM

2. creating plugins that get executed in the server to generate your own endpoint or middleware while being sure you can't start exfiltrating data (which can be other people's files, and other sensitive stuff)

3. in the workflow engine to enable people to run their own sandboxed scripts without giving those a blank check to go crazy

Or the people who write wasm don't talk too much about it. My OSS work (https://github.com/mickael-kerjean/filestash) has tons of it:

1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM

2. to create plugins that extend the backend and add your own endpoint or middleware as a way to enforce the code run in a constrained environment without the ability to send people's file out

3. in the workflow engine to enable people to run their own sandboxed scripts without giving those a blank check to go crazy

Nothing around content addressable storage? Has anyone used something like IPFS / Kubo in production at that kind of scale?

(for those who don't know IPFS, I find the original paper fascinating: https://arxiv.org/pdf/1407.3561)

> My prediction is that one of the many sandbox providers will come up with a nice API on top of this that lets you do something like ... No worrying about FUSE, the sandbox, where things are executed, etc. This will be a huge differentiator and make virtual filesystems easily accessible to everyone.

I've done exactly that with Filestash [1] using its virtual filesystem plugin [2], which exposes arbitrary systems as a filesystem. It turns out the filesystem abstraction works extremely well even for systems that are not filesystems at all. There are connector for literally every possible storage (SFTP, S3, GDrive, Dropbox, FTP, Sharepoint, GCP, Azure Cloud, IPFS....), but also things like MySQL and Postgres (where the first level folder represent the list of databases, the second level is tables that belong to a database, and each row is represented as a form file generated from the schema), LDAP (where tree nodes are represented as folders and leaf are form files), ....

The whole filesystem is available to agents via MCP [3] and has been published to the OpenAI marketplace since around Christmas, currently pending review.

ref:

[1]: https://github.com/mickael-kerjean/filestash

[2]: https://www.filestash.app/docs/guide/virtual-filesystem.html

[3]: https://www.filestash.app/docs/guide/mcp-gateway.html https://github.com/mickael-kerjean/filestash/tree/master/ser...

I use WASM extensively in my OSS work with Filestash (https://github.com/mickael-kerjean/filestash ) in 3 main areas:

1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM: https://github.com/mickael-kerjean/filestash?tab=readme-ov-f...

2. to create plugins that extend the core application. As of today, you can add your own endpoint or middleware in Filestash, package it with its own manifest, and run server-side code in a constrained environment. For example, there is a libreoffice wasm edition that can run from your browser but requires a couple HTTP headers to be sent by the server to work so the plugin has this bit that run server side to add those HTTP headers: https://github.com/mickael-kerjean/filestash/blob/master/ser...

3. in the workflow engine to enable people to run their own code in actions while ensuring they can't fuck everything up

Articles like this shitting on WebDAV really rubs me the wrong way as I've seen first hand discussion that goes like: "internet say WebDAV is hell, what's the better alternative? S3 or course!" And now every cloud provider instead of providing a webdav interface provide an S3 one and it's worse by every possible way, you can't rename a file / folder because S3 does not support that, you can't support a classic username / password authentication mode but are force to use an uggly access_key_id and secret_access_key, can't bash your way around with a simple curl command to do anything because generating the signature requires a proper programming language and you have to trust Amazon to do the right thing instead of going through the RFC process except they've already shown a few months ago their complete lack of care for any s3 compliant server by introducing a breaking change that literally broke the entire ecosystem of "S3 compliant" implementations overnight and without any prior warning.

I hope WebDAV had a better reputation, it carries the original promise of s3 of being actually simple but S3 won the war with evangelism. I would much have preferred a world where new version of the webdav protocol are made to address the quirks exactly like what happened with protocols like http, oauth, ...

In section 6: "tar files ... of the Linux kernel sources ... version ... 1.99.10 ... are approximately 24MB in size ... Out of the 2441 files in the 2.0.0 release 291 files had changed"

It never crossed my mind Linux at some point only had 2441 files and you could actually parse the code that went through a new version, that time has sailed

because it is "web scale"

ref: https://www.youtube.com/watch?v=b2F-DItXtZs

is there some open source product who can leverage this or this just assume you have to use Microsoft stuff?

I launched Filestash [1] as my response to the infamous “Dropbox should just be FTP” comment. Once I had a decent FTP experience, I kept going: adding support for pretty much every storage protocol, plugins to expose Dropbox (or anything else) over FTP, SFTP, MCP, or S3, and all the features I wished Dropbox had, with plugins to customize everything.

The base product is open-source and I make money from custom builds, additional plugins, paid support, and the occasional extra feature for companies with specific needs. It's a bit more than noodle profitable but quite under a normal salary.

[1] https://github.com/mickael-kerjean/filestash

The benefit is "Distribution". If your users are there, you want to address them wherever they already are, this is why apple store / play store / amazon store ... are so popular. Becoming a platform / ecosystem is the common playbook to go from being a one product company to an ecosystem / platform worth a lot more

I had a X250 who died less than a month after the warranty, now got a E14 since ~2 years and it got keyboard issues

Is this some sort of supabase but with sqlite and without the operational complexity?

emacs is quite approachable because of its self documenting nature. In practice, if you want to drill down on a particular thing, you need to use some of the describe-* commands. For example want to know how emacs save something?

1) find the command it uses with describe-keybinding, you find the command "save-buffer"

2) "describe-command save-buffer" brings you onto the lisp world where it is defined => "files.el"

3) want to know how a variable is define within files.el? "describe-variable buffer-file-name" and now you are in C territory

4) rinse and repeat with some describe-function when needed

5) get lost onto the beauty of emacs which in my opinion is its interactive / self documenting nature which unfortunatly is not more common in all the software we use

My first job out of uni was in creating automated tests to validate some set top box. It involved using library of "blocks" to operate a remote control. Some of the people I have been working with spent their whole career in this narrow area, building those libraries of block and using them for customer and I have no doubts a LLM can today produce the same tests without any human intervention

this is fine indeed if you didn't ask for my time

In my experience, having MIT and UCI as customers, US universities are much easier to deal with small to no process for simple cheap things. On the other hand, I was contacted by a well known engineering school in France (ENSEEIHT), they wanted support but were laughing at the idea to spend 20$ per month for the privilege, left the impression they wanted to use my time for way under minimum wage, same yesterday with a deutch school who wanted help but not willing to spend a dime, and some other universities who have deployed my software in prod but did not upgrade in the last 5 years. Even in China, I stumbled upon a fork maintained by the university of Shangai, of course they never reached out in the first place to ask for any kind of support, just took the code and went their own way. This kind of behavior haven't happen with US universities which are more likely to reach out and pay for support

This is not as simple as it sounds. Just yesterday I had a call with the Delft university of technology in Netherland, they want me to add some features on the free version of my FOSS product [1] but they did not want to pay anything. Over the last month, I was in contact with a 800B publicly traded company for a 1.8k per year invoice, once we agreed on the general direction they kept adding expectations, first was to sign tons of paperwork with their security checklist, legal stuff which took a few days but when they start asking for things that would take potentially weeks more, I invite them to do extras on a contracting basis, since them I have never heard back and of course they never paid a dime. I have literally tons of stories like this from governments to F500. In my bubble the paid support plan mostly work with US entities.

[1]: https://github.com/mickael-kerjean/filestash

Yesterday I received this message from a random github user: "Seriously. No SSO at all in free version? This is poor. Very very greedy and poor" [1]

If you do not spend a lot of time explaining things at length, people will link back to how much an asshole you are.

[1]: https://github.com/mickael-kerjean/filestash/issues/661#issu...

Would love to know more about the underlying tech

I always found fascinating the power section of valve amp for guitar will always be made of a very basic rectifier circuit to convert AC to DC that requires a expensive transformer and produce power with a terrible efficiency compared to more modern SMPS. Why is it nobody interested in valve amp never go the SMPS path? Is it all because sag is a desirable sound distortion?

> There is no community around growing its usage

I just added support for perkeep in Filestash last week (https://github.com/mickael-kerjean/filestash)

I once heard one such entrepreneurs (Éric Larchevêque) defining luck as "preparation meeting opportunity"

I made one such lightweight alternative frontend: https://github.com/mickael-kerjean/filestash

I use rxjs day in day out for my oss work (eg: https://github.com/mickael-kerjean/filestash/blob/master/pub...) It's quite common to see job description where I live (Sydney) with rxjava but reactive libs are a bit of a niche thing mostly because it takes a bit of time to be proficient at it + not many people talk about it but it's not sexy

> React is a lot more stable than I think you're giving it credit for.

That's until you have to use it in a real project, for a long time the go to solution was the facebook maintained CRA which is now deprecated. I have spent a lot more time than I'd like to admit migrating webpack versions when it was considered best practises to use class component with decorator but decorator never was standardised in the browser and was never able to get a clean project where running npm install would not give scary warning our project had high vulnerability that was dependencies of dependencies in CRA to the point that it got me wondered that even if the creator of react facebook can't get their shit together, the whole ecosystem is doomed. I have been outside the ecosystem for a year and looking at the shit show that is nextjs it seems things are even worse than before.

The frontend of my main OSS work was made is plain es6: https://github.com/mickael-kerjean/filestash

The frameworky code is under 100 lines of code, heavily inspired by what I think is a good idea from React: "components are pure function", the simplest example of the about page beeing visible here: https://github.com/mickael-kerjean/filestash/blob/master/pub...

Since the whole project was migrated over from React, I was able to improve performance to a degree that would have been impossible using React, it's a breadth of fresh air to open the performance and memory tab and to be able to optimise things from there to get 60FPS no matter what whilst preventing massive ram usage because those frameworks runs all sort of code that is out of your control. Also because there is no build system, I was able to introduce plugins to be able to patch frontend code via patch applied dynamically by the server to create features like the recall button to recall data stored on glacier when using S3, dynamic patching of the icons to apply branding and many other things that I would have had to fork entirely before

Anyway, I hope our industry would go more often the vanilla route, es6 is ready for prime time and solve all the pain point we had while internet explorer was still a thing