New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: why not collaborate with KeePassX? #43

Closed
samrocketman opened this Issue Oct 16, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@samrocketman

samrocketman commented Oct 16, 2016

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).

@samrocketman samrocketman changed the title from re: keepassx reboot to re: keepassx reboot; why not collaborate Oct 16, 2016

@samrocketman samrocketman changed the title from re: keepassx reboot; why not collaborate to re: keepassx reboot; why not collaborate? Oct 16, 2016

@TheZ3ro

This comment has been minimized.

Member

TheZ3ro commented Oct 16, 2016

(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

@TheZ3ro TheZ3ro changed the title from re: keepassx reboot; why not collaborate? to Discussion: why not collaborate with KeePassX? Oct 16, 2016

@TheZ3ro TheZ3ro added the discussion label Oct 16, 2016

@droidmonkey

This comment has been minimized.

Member

droidmonkey commented Oct 16, 2016

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

This comment has been minimized.

samrocketman commented Oct 16, 2016

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

This comment has been minimized.

Member

TheZ3ro commented Oct 16, 2016

@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

This comment has been minimized.

drdaeman commented Jan 24, 2017

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

This comment has been minimized.

Member

phoerious commented Jan 24, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment