Can We Fork and Publish FoF Extensions?

huseyinfiliz

Hey, i wasn’t sure where to open this topic or how to reach the FoF team directly, so I decided to try reaching out here.

I’m developing an extension forked from fof/custom-footer, which can be found at the following GitHub repository:
huseyinfiliz/modern-footer

This extension doesn’t work exactly the same as the original. Instead of a toggleable footer controlled with JavaScript, it functions more like the demo shown in the following CodePen:

Currently, the extension has been stripped of its ties to the original custom-footer and includes its own settings. Before proceeding with further development, I wanted to ask for permission from the FoF team.

If the FoF team wishes, they are welcome to incorporate my changes into their own extension and publish it. However, I doubt that will be the case, as the current custom-footer extension doesn’t feel very modern or aligned with Flarum’s design language. I believe there’s a need for a new footer extension that is both modern and customizable.

I’m planning to build an extension that is fully configurable from the settings panel and offers a high degree of customization. For now, I’ve only made the extension functional and stopped development to avoid going further without your permission. In summary, I’d like to build my own modern footer extension while using the custom-footer extension as a foundation to speed up development.

The extension is currently published as huseyinfiliz/modern-footer on Packagist and can be installed for testing.

I look forward to hearing suggestions, advice, or warnings from the FoF and Flarum teams. Thank you!

Umutcan

huseyinfiliz Thank you for your efforts, I think it definitely deserves a review. I congratulate you for your contributions to the ecosystem. 👏👏

huseyinfiliz

clarkwinkelmann Thank you for your valuable and detailed explanation. I would also like to express my gratitude once again for your contributions to Flarum.

Following your advice, and to avoid any potential issues regarding fork policies in the future, I will separate the project from the custom-footer fork and convert it into a standalone repository.
https://stackoverflow.com/questions/38831301/how-to-unfork-a-github-repository

Umutcan Thank you so much for your kind words and support! I truly appreciate your encouragement and am glad to contribute to the Flarum ecosystem. Your feedback means a lot, and I will continue working to improve the project

clarkwinkelmann

As all FriendsOfFlarum extensions are licensed under MIT (I believe, but best to double-check for each specific extension) you are of course free to do anything with the code as long as you keep the authors copyright mention as required by the text of the license.

I don't think we have any official policy at FriendsOfFlarum for extensions fork. My personal stance has always been that bugfixes or small quality of life improvements should be contributed to the existing extension. Translations should be contributed to the language packs. Then any major refactoring of an extension would necessitate a discussion with the other developers to decide if we want to take on the maintenance of those new features. So for me, if you are creating a more advanced version of one of the FoF extensions and are willing to take on its maintenance, then it absolutely deserves to be its own new extension. You will also have more flexibility if you are still developing features or want to take it into a different direction later on.

When it comes to forking, the other thing to watch out for are Packagist terms of service and the Flarum extension directory policy. If someone makes a fork of a package for the sole purpose of fixing a bug or making cosmetic changes, it might fall under their forks policy and be rejected (I have not read their terms of service in a while though, so it could have changed). I don't think Flarum has a written policy for the extension directory, but forks that don't add anything of value are usually hidden from the directory to reduce noise and confusion for end users.

If someone wants to make a fork of an extension to customize it for their personal use case and don't plan to share it with others, Packagist should not be used. The fork can be installed through a local Composer repository or Packagist.com. (this is clearly not what this discussion is about, but I'm including this for completeness)

Both to avoid any fork policy issue and for the benefit of the end users, try to name the extension in a way that's easily distinguishable from the original. Of course drop "FriendsOfFlarum" from the name, and then if you have "Modern" in the name I think this is clear enough distinction that this is a different version with different features. Make sure the links in your README and in composer.json point to your own GitHub/Packagist/Discuss so people don't end up in the wrong place to ask for support.

huseyinfiliz

clarkwinkelmann I couldn't configure the npm build process in GitHub Actions; I was handling it locally. However, the npm build command works in the extension I forked. I couldn't find sufficient documentation on this. Can you recommend a guide on how to achieve this for the huseyinfiliz/flarum-member extension?