11–20 of 143 posts
Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
However, humans being humans egos etc get in the way.
Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
Lazarus, and to a lesser extent Free Pascal, are basically like that. New features are added often and bug fixes to code written by others who aren't around (or don't have time) are submitted all the time (e.g. personally i'm more of a user than a developer of the project but i always use the git version built from source so that i can quickly fix any bugs that annoy me). The codebase is also far from small and the project is an IDE that tries to do "everything", so far from "doing one thing".
Lazarus has been around for at least a couple of decades, so i think that shows projects do not necessarily die when doing that.
It might have to do with not having some big company push their weight around so it is largely community developed and driven. Also it is by far the most popular IDE for the language it is written on, so perhaps it is easier to find contributors.
Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
Years back I worked on a search engine abstraction library for Django. I’m not sure the concept is affordable at all - search engines are less alike than SQL databases — but one thing we constantly had problems with was that most volunteers only needed one backend but any new abstraction would need to be implemented for at least 3.
Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.
The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually).
If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just a view of what people wants and not how the project should go.
Also react-native-fs mentioned in the article only have 4 bugs opened. The rest is just noise and unlabelled issues. Note that there might be a considerable amount of bugs in those unlabelled issues.
As a maintainer I should not spend my time to label anything, either you enter it as bug and I'm considering it since bug are supposed to be critical, either it's not and it's going into a sperate queue I can read whenever I have more free time.
The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just…
Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM...
Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.
Low dependency analysis is one of the reasons I like Flask[0]. [0] https://github.com/pallets/flask/blob/main/setup.py
Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and up to two timezone related backports depending on your OS (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite.
And with that you get a lot more for less, compared to a Flask + wtforms + sqlalchemy + alembic "starter setup":
> $ pip install flask "sqlalchemy[postgres]" wtforms alembic
> $ pip freeze | wc -l
> 13
> $ pip install django psycopg2-binary
> $ pip freeze | wc -l
> 4