Discussion: why not collaborate with KeePassX?

[samrocketman]

Is there some reason you were not able to collaborate with the original keepassx project? Forks typically have negative effects on a community (there are examples I can cite if asked).

[TheZ3ro]

(the views expressed are my own, I speak for myself and not for the whole KeePassX Reboot Team)

In open source and free software, forks are a good thing.
Forks can happen only when a software is truly open source, and this empowers the open source community.

KeePassX is licensed under GPLv2 or GPLv3, so it's Free Software.
According to Stallman and his 4 Software Freedom:

[...]
3. Freedom to contribute to your community. That’s the freedom to distribute copies or modified versions when you wish.

So it's totally fine to modify or fork Free Software.

The problems with KeePassX that led to the Fork are the following (maybe I miss some...):

• The development of the project proceeds very slowly and KeePassX lacks lot of feature from KeePass
• There are 69 opened pull request (without maintainer comment) that wait to be merged

So we started KeePassX Reboot to merge all the never-merged pull request from the community.
This includes the keepasshttp support and all the Issue that are currently opened in the KeePassXR project.

If the original maintainer of KeePassX in the future will be more active and will accept our merge and changes, maybe we should consider to re-merge and collaborate.

PS: There are no Security problem with KeePassX or keepasshttp, just a matter of usability.
You can go on and use KeePassX without problem or join KeePassX Reboot project for future update and support.

TheZero

[droidmonkey]

Agree with @TheZ3ro. This "fork" is not without basis, quite the contrary, we discussed this possibility on the KeePassX repo for several months before making the move. Never has the maintainers of KeePassX chimed in.

Either way, this is not designed to be a "takeover" or "coups" since we are moving the project in a direction that the community dictates. Adding features deemed necessary for a modern day, cross-platform, offline password manager. You are free to use KeePassX in its original form if you like.

[samrocketman]

I was not stating your fork is wrong, without merit, or violates any licenses. I'm merely asking the hard question because:

• Forks can cause community splitting which strains the resources of both projects.
• Forking can be expensive because with two projects of the same you basically have double of everything (I'm thinking build and support infrastructure). Though, using GitHub and things like Travis CI make it a non-issue since it's free but still a point to be made.
• Contributors
  • Existing contributors have to decide which project they're going to support. Very rarely does a contributor contribute to multiple forks of the same thing because volunteer time is a rare and valuable resource.
  • New contributors have to decide which project they're going to get behind and contribute.
  • In the end, both projects can possibly suffer from a lack of contributions where if they were combined it may be less of an issue.

Sometimes forks are necessary (see LibreOffice for example forking from OpenOffice; which was a good thing). Sometimes forks are harmful (see io.js vs node.js where they forked, suffered apart, and decided to merge the communities again).

Personally, I try to keep communities together as much as I possibly can without a fork. I just want to be sure we're all on the same page as to why you want this fork and not simply contribute to the upstream project.

The problems with KeePassX that led to the Fork are the following (maybe I miss some...):

• The development of the project proceeds very slowly and KeePassX lacks lot of feature from KeePass
• There are 69 opened pull request (without maintainer comment) that wait to be merged

This seems reasonable.

If the original maintainer of KeePassX in the future will be more active and will accept our merge and changes, maybe we should consider to re-merge and collaborate.

Thank you very much for being willing to answer my question. Your fork does sound reasonable and hopefully in the end both communities merge again to keep the project strong. If as a result KeePassX becomes irrelevant in lieu of the fork because they're ignoring contributions so be it.

I think the most desirable outcome (in my mind) would be that you guys are given co-maintainer status and it's not waiting on a single person to be a bottleneck for testing and merging contributions.

[TheZ3ro]

@samrocketman asking is totally fine, lots of people (on reddit) asked why the fork happened so I sum-up all the questions in a single answer trying to be as clear as possible 😃

For everyone that want contribute (or has contributed to KeePassX in the past), you are welcome!

[drdaeman]

Just a suggestion: please consider mentioning when the fork had happened in the CHANGELOG file, so users looking for differences overview can quickly grasp what's new in KeepassXC. I suppose it's 2.1.0 release, but I haven't tracked the original project progress so not sure.

[phoerious]

There was an intermediary 2.0.3-http release also. We have some plans regarding KeePassX and KeePassXC, they only need to mature a little more.

[TheZ3ro]

(the views expressed are my own, I speak for myself and not for the whole KeePassX Reboot Team)

In open source and free software, forks are a good thing.
Forks can happen only when a software is truly open source, and this empowers the open source community.

KeePassX is licensed under GPLv2 or GPLv3, so it's Free Software.
According to Stallman and his 4 Software Freedom:

[...]
3. Freedom to contribute to your community. That’s the freedom to distribute copies or modified versions when you wish.

So it's totally fine to modify or fork Free Software.

The problems with KeePassX that led to the Fork are the following (maybe I miss some...):

• The development of the project proceeds very slowly and KeePassX lacks lot of feature from KeePass
• There are 69 opened pull request (without maintainer comment) that wait to be merged

So we started KeePassX Reboot to merge all the never-merged pull request from the community.
This includes the keepasshttp support and all the Issue that are currently opened in the KeePassXR project.

If the original maintainer of KeePassX in the future will be more active and will accept our merge and changes, maybe we should consider to re-merge and collaborate.

PS: There are no Security problem with KeePassX or keepasshttp, just a matter of usability.
You can go on and use KeePassX without problem or join KeePassX Reboot project for future update and support.

TheZero

[droidmonkey]

Agree with @TheZ3ro. This "fork" is not without basis, quite the contrary, we discussed this possibility on the KeePassX repo for several months before making the move. Never has the maintainers of KeePassX chimed in.

Either way, this is not designed to be a "takeover" or "coups" since we are moving the project in a direction that the community dictates. Adding features deemed necessary for a modern day, cross-platform, offline password manager. You are free to use KeePassX in its original form if you like.

[samrocketman]

I was not stating your fork is wrong, without merit, or violates any licenses. I'm merely asking the hard question because:

• Forks can cause community splitting which strains the resources of both projects.
• Forking can be expensive because with two projects of the same you basically have double of everything (I'm thinking build and support infrastructure). Though, using GitHub and things like Travis CI make it a non-issue since it's free but still a point to be made.
• Contributors
  • Existing contributors have to decide which project they're going to support. Very rarely does a contributor contribute to multiple forks of the same thing because volunteer time is a rare and valuable resource.
  • New contributors have to decide which project they're going to get behind and contribute.
  • In the end, both projects can possibly suffer from a lack of contributions where if they were combined it may be less of an issue.

Sometimes forks are necessary (see LibreOffice for example forking from OpenOffice; which was a good thing). Sometimes forks are harmful (see io.js vs node.js where they forked, suffered apart, and decided to merge the communities again).

Personally, I try to keep communities together as much as I possibly can without a fork. I just want to be sure we're all on the same page as to why you want this fork and not simply contribute to the upstream project.

The problems with KeePassX that led to the Fork are the following (maybe I miss some...):

• The development of the project proceeds very slowly and KeePassX lacks lot of feature from KeePass
• There are 69 opened pull request (without maintainer comment) that wait to be merged

This seems reasonable.

If the original maintainer of KeePassX in the future will be more active and will accept our merge and changes, maybe we should consider to re-merge and collaborate.

Thank you very much for being willing to answer my question. Your fork does sound reasonable and hopefully in the end both communities merge again to keep the project strong. If as a result KeePassX becomes irrelevant in lieu of the fork because they're ignoring contributions so be it.

I think the most desirable outcome (in my mind) would be that you guys are given co-maintainer status and it's not waiting on a single person to be a bottleneck for testing and merging contributions.

[TheZ3ro]

@samrocketman asking is totally fine, lots of people (on reddit) asked why the fork happened so I sum-up all the questions in a single answer trying to be as clear as possible 😃

For everyone that want contribute (or has contributed to KeePassX in the past), you are welcome!

[drdaeman]

Just a suggestion: please consider mentioning when the fork had happened in the CHANGELOG file, so users looking for differences overview can quickly grasp what's new in KeepassXC. I suppose it's 2.1.0 release, but I haven't tracked the original project progress so not sure.

[phoerious]

There was an intermediary 2.0.3-http release also. We have some plans regarding KeePassX and KeePassXC, they only need to mature a little more.