Questions about long term viability

[dsdole]

Hi, I just discovered this project and I have to say it really interests me because seafile is one of my most critical services and is the only one which I've been having trouble running in kubernetes. I am considering switching over however I am concerned about the viability of the project. Specifically:

• Do you believe it is likely that future issues may arise which will prevent you from maintaining this project?
• Would you be wiling to add developer documentation which would make it easier to understand how this project is built and packaged (docs for scripts, reasons behind architectural decisions, etc...)?
• Is it possible to migrate from this project's seafile back to an upstream deployment?

Thanks for the work you've done here, I look forward to the discussion.

[kirisakow]

Disclaimer: I'm not affiliated with this project, I'm just another user in the crowd, and my opinions are my own.

@dsdole Are you hearing yourself, kid? 🤦‍♂️
This is a FOSS project, not a commercial product.
It's about goodwill and best effort, not warranties and guarantees.
It's meant to make one's life easier, not make one's business bigger.

[dsdole]

I figured that this would annoy someone but that wasn't my intention. I only run seafile for my own personal use and I'm only curious. There are many open source projects which do publish information like project charters and documentation for developers who might want to make their own PRs. Perhaps I could have worded it better but I am not making any demands, purely asking questions.

I do not believe insults are warranted either.

[ggogel]

@kirisakow, thank you for your support. I agree with your points, but let's keep the tone respectful to maintain a constructive dialogue. Everyone's feedback is valuable for the project's improvement.

[ggogel]

Do you believe it is likely that future issues may arise which will prevent you from maintaining this project?

Sadly, I don't have a magic crystal ball. I can't foresee personal life changes or specific long-term decisions from the Seafile team. However, I'd like to address my concerns regarding Seafile's current development trajectory.

Firstly, not all Seafile software is open-source. For example, the pro edition and some clients are closed-source.

Secondly, many essential features are restricted to the pro edition. Features like setting fine-grained permissions on shared folders should be part of the Community Edition.

Thirdly, the focus on additional modules like SeaDoc, which uses a proprietary file format and is incompatible with established Office formats, seems unnecessary when excellent tools like OnlyOffice already exist.

I appreciate Seafile for its simplicity and reliability, which is why I switched from Nextcloud. However, I'm concerned Seafile might follow Nextcloud's path by prioritizing additional modules over core functionality.

Long story short, I'll continue maintaining this project as my time permits. However, I am subject to the Seafile team's decisions. If Seafile becomes impractical due to implementation or licensing changes, that is beyond my control.

Would you be wiling to add developer documentation which would make it easier to understand how this project is built and packaged (docs for scripts, reasons behind architectural decisions, etc...)?

The necessary documentation is already available in this repository or the official Seafile documentation. This repository just provides an unofficial alternative deployment method for Seafile. It includes deployment artifacts, integration artifacts, and scripts handling things such as managing the container lifecycle and bootstrapping, none of which would justify any further documentation.

Is it possible to migrate from this project's seafile back to an upstream deployment?

Again, this project is an unofficial alternative deployment method for Seafile, not a fork. It does not have any special configuration, nor does it persist data differently, such that it would make the configuration or persistent data incompatible with any official deployment method. Therefore, migrating back to any official deployment method should be straightforward.

[dsdole]

This repository just provides an unofficial alternative deployment method for Seafile. It includes deployment artifacts, integration artifacts, and scripts handling things such as managing the container lifecycle and bootstrapping, none of which would justify any further documentation.

That's great to hear. I guess I'll be testing it out today itself. Thanks for your quick response!