-
Notifications
You must be signed in to change notification settings - Fork 110
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
Ensuring the survival of this project #361
Comments
Hi Ivan, I'm glad to hear that this project is useful to you. I felt the same way about Org's built-in searching, which led me to eventually develop this. I'm not sure how popular it really is; projects like I'm happy to talk about the future of the project in a broader sense. I've no intention to stop working on it, but due to work and family issues, I haven't had as much time to work on Emacs-related projects in general for the past year or two. I'm also now working as a contractor/developer, which leaves less time for FOSS projects. Others have suggested accepting donations for my Emacs/Org-related projects before, and I've considered it, but never set it up. I'm still open to the idea; probably I would set a personal hourly rate and then promise to work on the projects at least as many hours as a month's donations would fund, or something like that. Something else to consider is the project's hosting and licensing. It's always been on MELPA, but I wouldn't mind getting it into GNU ELPA, which might help ensure it's longevity. There's also been discussion of potentially integrating it into Org itself someday, but I haven't pushed for that; I still have some plans I'd like to accomplish without having to go through the larger Org development process. In the long run, though, that would be nice. There's another issue here on the tracker somewhere where @yantar92 and I talked about that. Of course, that raises the issue of licensing; were it to be a GNU ELPA package or part of Org, copyright of contributions would have to be assigned to the FSF, like contributions to Emacs itself. There's at least one PR on here where I mentioned that possibility and asked the contributor if he'd be willing to do so. It's a decision that probably needs to be made firmly one way or the other so as not to impede further development or make it harder to change the decision later on. In general, I'm glad for more people to contribute to the project. One of the challenges is ensuring that contributions are of high quality, come with tests as appropriate, etc. Sometimes it can be more work to usher a PR through that process than to do it oneself, so that's why some outstanding PRs may seem stalled. But, personally, I subscribe to the Debian bug tracker's philosophy: it's okay for a patch or report to remain open, as long as it's intended that it be solved eventually. I appreciate the concern and the kind words. Being reminded that some users are awaiting further developments is encouraging; I'll try to find some time to work on org-ql soon, although the coming month looks to present some challenges in that regard. Hopefully this response is useful and helpful. Please let me know any further thoughts you may have. |
For future reference, @yantar92 and I spoke on Reddit, and we're both in favor of upstreaming |
Hi,
This is not so much an issue with the code, as an attempt at having a conversation about how to ensure this project lasts and improves over the years.
First of all, let me say this project rocks, and I very much appreciate the effort you @alphapapa put (and keep putting) into creating it and maintaining it. I'm sure I'm not alone in this sentiment: the project has become super popular. I was about to abandon org-mode because search was becoming so inefficient, and discovering this saved my org (and my productivity!).
I've noticed that there have been fewer commits recently and, in a recent PR, you mentioned "[...] I haven't had much time to work on this project recently."
Open source projects often die as people move on to other things (because life happens), take on other responsibilities, get jobs that are incompatible with working on these projects, etc. In principle, because it's open source, anyone could fork it. In practice, I fear that that would not really happen. Since you have contributed almost all code, this project would be at risk of dying if for some reason you couldn't contribute to it as you have.
I wonder if, in the long run, it would help the project more to gather more contributors, and facilitate that others integrate contributions (e.g., adding tests so contributions are easier to accept). It might also help to spend time reducing technical debt (should there be any; I'm speaking from experience with other projects, not anything in this specifically), to make it easier for others to go through the code.
If money could be a threat to your continued participation and to the project's survival in the long run, maybe donations could also be enabled.
I hope you don't consider it inappropriate that I mention this. My comment emerges from a place of appreciation for this work, interest in ensuring you can continue doing this, and desire for the project to live on.
(I'm not a lisp programmer myself. I could learn, and I do FP, although lisp might take time. I hope to contribute in some way or another.)
The text was updated successfully, but these errors were encountered: