1,563 karma · joined December 23, 2015
github: https://github.com/mickael-kerjean/filestash
From what I can see around me, the rate of oss dev who make a living out of their project is similar to amateur / pro football player, with the big star everyone talk about, namely redhat & gitlab. I only know personally 1 other oss dev who is doing better but still way under what you get working for someone else
If you're doing oss and managed to get things to work, please reach out to me, I'd love to talk to you.
You lost me there. WebDAV is nothing more than HTTP calls with some XML data with a slightly different syntax than the S3 API. There is no fundamental stuff in the spec that command the protocol to be "slower than dog shit" as a file transfer protocol. Please prove me wrong with another argument than: "the particular server implementation I tried was dog shit"
I was unsuccessful to convey the same message in my previous company (apart from being fired part). All around the codebase you'd see function with official argument and unofficial ones via ctx that would panic everything if you forgot it was used 3 layers down (not kidding). The only use case I've seen so far that is not terrible of context value is if you have a layer of opentelemetry as it makes things transparent and as a caller you don't have to give a damn how the telemetry is operated under the hood.
There's no track record of it but I believe it would be ok in the right team. The core idea was stolen from every other frameworks: "build your app as a tree of components". In the approach I went with, components are modular and expressed like this:
```
export default function (render, props = {}) {
render($domNode)
}
```
in practice, a working code loading another component would be: ```
import FooCompoment from "./component_foo.js";
export default function (render, props = {}) {
const $node = createElement(`
<div>
<div data-bind="component_foo"></div>
Name: ${props.name}
</div>
`);
// render the component with an animation
render(transition($node));
// render a child component
FooComponent(
createRender($node.querySelector(`[data-bind="component_foo"]`)),
{ ...props },
);
}
```
The syntax is arguably less nice than JSX but the upside is 0 running cost and the idea around decoupling components remain. A lot of people have argue that I just end up maintaining my own framework but the reality is what would be considered "framework code" fit under 200 lines of code ....It's refreshing to be able to open the network tab and see the original files coming out [2] and the developer console showing the full structure of it untouched in the same way it's visible from github.
This has opened new doors that was previously closed with any kind of framework, the option to dynamically patch those js file at runtime to customise the interface for unique needs that make sense for someone but wouldn't make sense for 99% of everyone else. Now it's just a matter of submitting a small plugin patch that do it and tada, a happy customer while maintaining only a single codebase
[1] https://github.com/mickael-kerjean/filestash
[2] https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...
Were you familiar with Filestash before starting this? If so, was there something specific you felt was missing that inspired you to create your own solution? Would love to hear your thoughts.
github: https://github.com/mickael-kerjean/filestash
demo on s3: https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...
The money come from customisation and enterprise plugins (SSO, audit plugins, etc..). The entire product was made so you can quickly build custom file management solution by assembling a bunch of lego blocks (aka plugins)
1. the demo instance of my OSS software which is a bring your own storage Dropbox like UI for SFTP, S3, FTP, and every protocols imaginable: https://github.com/mickael-kerjean/filestash People tend to come in the demo to upload / download tons of stuffs
2. the docker registry for my oss stuff since I was kicked out of the docker open source program and now need to find a new place to store all the images. 10 millions downloads over the last few years, it does add up very quickly way above the 20TB limits if your image isn't super slim and try to selfhost everything
Having very high expectations when using the software without contributing anything else than public shaming on something that clearly state in the license: "Licensor provides the Work ... WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" shouldn't be ok, this is quite literally how you make open source developer to burn out
then you should check this amazing sailor named Yann Quenet who built his own 4m sailboat [1] (yes 4m is crazy) on which he did a circumnavigation and once he came back worked at improving his little boat and just left 8 days ago for another circumnavigation.
He has been documenting his journey on youtube[2]:
ref:
2. extract emails of the contributors that are involved in what you need using something like this: git log --pretty=format:"%ad - %ae - %ce"
3. make them an offer
[1] framework code: https://github.com/mickael-kerjean/filestash/tree/master/pub...
[2] example: https://github.com/mickael-kerjean/filestash/blob/master/pub...