-
Notifications
You must be signed in to change notification settings - Fork 98
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
Development is not public #26
Comments
You are absolutely right: the development is not public. KeePassium is a personal project. I am personally responsible for 100% of its development and prefer to keep it that way. The motivation behind this is stated in the first lines of the readme:
Initially, KeePassium was planned as a proprietary app. I did not want to invest months of my life only to see somebody grabbing the code and publishing the app for free (this almost happened with KeePassB). However, releasing the source code was the only possible way to demonstrate clean intentions and make the app credible. Eventually, I had to choose between transparency and commercial safety. That was not easy and evolved through most bizarre stages. In the end, I took the risk and chose transparency. So, the purpose of this repository is to provide transparency. It is not intended to facilitate contributions or derivative work. That's why the commits are squashed, and comments and unit tests are scrubbed — all these factors do not affect the transparency, but improve project's chances of staying afloat in five years. P.S. As a side note, I would be happy to make commits more fine-grained. But that would require applying a bunch of fork-deterring steps (mentioned above) to every single commit in |
I can understand the intention but does the Apple Appstore not forbid these kind of forks?
This is a general issue with the Apple Appstore because the builds are not reproducible or verifiable. I think it would have been enough if iOS would allow to restrict Internet access for apps, like it is possible for Android, so there is no way your or any other app can leak data without the user noticing. In this case your app would have been much more credible then parts of it being open-source.
At the same time this is a one man project so if your priorities change KeePassium is gone. Of course this can happen to a publicly developed open-source tool like MiniKeePass too since the developers do not seem to have passed the access over to other interested parties but at least there is the option to take the code and release it under a new name. And do not get me wrong, it is not about money. I have donated 12 Euros to MiniKeePass in the past - because it was a great tool for my use case and I would have also bought it - but sadly the app seems to be gone for good. You could add a policy though that if you do not want to continue working on this project anymore, that you publish the whole source code or something like this. This would make it easier to buy the app I think, especially if it is more expensive. Anyway I wish you good luck with the project and will check it out as soon as it is released in the appstore. |
Yes, they forbid GPL forks on AppStore. Discovering this in October 2018 was exactly the nudge I needed to open-source the app. But this is just theory. In practice, I will have to monitor the AppStore for copycats and try to recognize them behind the modified UI. Even worse, I would have to prove to Apple that a vaguely similar proprietary app contains my GPL-licensed code. Lawyer fees, stress... A closed-source project would have been much, much easier to protect and commercialize.
Yes, this would have made things so much easier: the app cannot leak anything, so you don't have to trust the developer. Unfortunately, this is not a magic bullet:
I would disagree with the "parts" part of your sentence. There are no missing assets or precompiled binary blobs. Even third-party modules are directly included in the code. As it is, this repository compiles into a fully-functional KeePassium app. As for credibility, many people are perfectly happy with the "open source" badge. A few experts will actually audit and compile the code. The remaining few will not be happy with the badge nor willing to read the code. I don't really want to convince them — I would rather focus on building an incredible app (pun intended).
Yeah, this is a frequent argument... against Bitwarden. But there is one important difference: KeePassium does not need servers. (MiniKeePass still runs just fine, right?) I can see why MiniKeePass' priorities changed: the app was free-as-in-beer. For KeePassium, being a paid app is the best guarantee that it will be maintained. If the app is profitable and my priorities change, it seems fairly simple to hire someone else to work on the project. Otherwise, one just cancels their subscription and stops supporting a dead app. If I get run over by a bus, there will be nobody to complain about eventual forks. (Only the copyright holder can file a DMCA takedown request.)
Not really. Nobody may publish MiniKeePass fork on AppStore without their explict permission (see the first paragraph, about GPL forks).
Well, the last time my priorities changed, I did exactly that: released a proprietary app under the MIT license. However, there is not much point in making this a commitment: people who need convincing are not my target auditory. There are plenty of people who are stuck with an ugly or outdated app. They know exactly what they need and how KeePassium delivers that. I make KeePassium for them.
Thanks! |
Thanks for the explanation. |
By coincidence, this morning I needed to reference a few lines in KeePass source code, but... could not find its repository. A quick search discovered that KeePass — a one-man project, by the way — does not have a repository: Dominik simply publishes snapshots of stable versions. So, there's that. |
@rdxmb , when someone asks about KeePass implementation details, it would be odd to cite KeePassXC instead :) |
BTW, starting from Feb 2021 commits are no longer squashed, for the sake of transparency. |
I see. I do only use KeePassXC - I did not know KeePass is still a project which is maintained. |
I and several other people have resorted to maintaining our own repos based on the snapshot. I have a few customizations and getting the guy a patch is a pain since he doesn't have a public repository for some reason. I read his response and reasoning which isn't really a reason other than "I don't want to do it" and he also seems to think that doing so would impose some great burden of maintenance. I'm guessing he has never used github. |
Well, I kinda understand the "burden" part. Keeping a pristine public repo does take some time, especially for someone with mainly solo experience (speaking from my solo experience here :) Merging a PR can easily take a couple of days. After all, a non-trivial PR is more of a suggestion, a shortest-path solution. The maintainer is still responsible for review, refactoring, considering edge cases, code style and testing. Plus, there is time pressure:
So the burden of maintenance is real... |
I am looking forward to KeePassium's release but in my opinion the development is not public.
The commits are not atomic and a huge combination of different changes so it is hard to follow and track. This setup also does make it harder for others to contribute to the project.
Not to mention that KeePassium is a security sensitive open-source software but you seem to have a private repo or separate development infrastructure and only commit the final stages in this repo.
Why are you not using this repository for the every day development if you really want KeePassium to be open-source?
The text was updated successfully, but these errors were encountered: