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 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.
Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues.
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.
I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.
It could still be worth saying "no", per the article, to the 295 open feature requests. The fact that the maintainers have not (yet) declined these requests, resulting in this seemingly inflated total of 300 "Issues", is not necessarily a problem with github.
Personally I skim a sample of issues before adding a dependency. The main thing I look at is what happens after high quality bug reports are filed. The top line number doesn't bother me much.
It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"
When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.
GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.
I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.
The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening them are disciplined (and pay attention) enough to file them in the right category. Just because there's a separate "feature request" top-level tab doesn't mean that nobody will ever open a "bug" asking for a "feature". Especially if not everybody is allowed to ask for new features.
And I'm not even going into the difference between "improvement" and "feature" requests.
> To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.
The difference is that they're all under the label "issues" implying it's something that needs to be fixed. Sure, you could label it, but that's a workaround and it's still in a category called "issues".
A feature request should have a different life cycle. In that regard it should be more like a PR, where you submit a request, it gets feedback and is resubmitted etc. All with a history that's clearly visualized, so it's easy to compare the different revisions.
I find it quite difficult to follow the discussion around a non-trivial feature request when it's just a regular issue.
It is not a semantic problem. "Issue" was an very broad term far before it was used in software development / project management. It's meaning easily encompasses far more than just bug reports. This is why we have labels to break issues down into other categories. Some issues are purely discussion topics, some are change requests, some are bug reports. You seem to be trying to restrict the meaning of 'issue' in a way that matches neither current usage, nor historical usage.
You may disagree that it's a problem, but what I'm referring to has nothing to do with marketing and everything to do with the semantic meaning of the word.
The actual semantic meaning of the word "issue" is broad and doesn't support any of your arguments. You seem to think "issue" means something different from how the rest of the world uses it or has used it.
Ok, so? That means you disagree about me on whether it's a problem, which is fine.
When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.
Concern about the negative emotional connotation of a word instead of that word's semantic meaning is a classic "marketing" concern, but whether or not we call your concern one about "marketing" (which is itself a very broad term) seem irrelevant to that actual substance of your concern.
Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means.
> Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.
Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
> Holy shit. You are disagreeing with me about the meaning of a term.
I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in.
If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue.
> Only if you want to keep everything about the UI the same except for the word used for what's currently called "issues". That's not something I have expressed any sort of desire for.
We currently have a broad category of things, these things need to have a name. You seem to think that "issue" is a bad name for this category of things, so I am asking: what you think is a better term for this category?
We can further break down that category into "bug reports", "feature requests", "change requests", "discussions" and add better UI elements to surface those groups but the overall system that manages these all these items still needs a general name for what it is managing.
Listen, I'm done with this discussion. For the second part of your comment I already linked you to this comment: https://news.ycombinator.com/item?id=33774066. For the first part, everything I can find on the topic indicates that connotations are part of semantics; it's a part of the word's meaning, after all. If you disagree with that, fine, I don't care, I have made it as clear as I can possibly be that nothing I've said has anything to do with marketing.
"meaning" itself is a broad term, but the "literal meaning" AKA the "denotation" is distinct from the "connotation" of a term. Semantics is a broad term that means different things in different disciplines, but generally concerns itself with the denotation more than the connotation. I suppose you could make an argument that the denotation of "semantics" could technically include connotation but that the connotation of "semantics" usually implies that it is denotation that is being discussed.
Instead of arguing the different definitions of the word "semantic" with me, why not just listen when I say that I'm not talking about marketing. Please.
I've mentioned "marketing" exactly once, and only to dismiss the debate about what is and isn't marketing as irrelevant. I've tried to constructively drive the conversation forward repeatedly, if I've been drawn into side discussions, it is only by you bringing up those topics.
I also disagree with you about how you're treating the term. "Issue" is used more broadly from a user perspective.
As a user it legitimately is an issue, in the commonly used sense, if you cannot do what you need to do with software, even if that software is working exactly as designed and no one has yet flagged some alternate functionality to add with an enhancement.
> When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation.
That's a you problem.
Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.
A feature request is very much something that should be discussed.
> Maybe I'm just wrong,
Yes, you are. Rather than push back, accept it and move on.
> GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.
Except that GitHub Issues originally only encompassed bugs. Labels weren't added until later that allowed you to filter by "type". Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system", so I wouldn't say that it's so "clearly defined".
> Also, GitHub Discussions are for discussions, not GitHub Issues. GitHub themselves say that Issues is "often referred to as GitHub's bug-tracking system"
That quote is directly below a quite clear explanation of what issues are for: "are useful for discussing specific details of a project such as bug reports, planned improvements and feedback."
Each project can decide for themselves at where they draw the line in terms of what they want where. That is a good thing, it makes github issues flexible for a wide range of projects that are organized in a wide variety of manners. It seems like a shame to lose that flexibility to make it easier for people who are too lazy to do more than look at the count of open issues when evaluating the health of a project.
Maintainers obviously have to go through and re-label or move issues as appropriate. The situation is the same now; if someone creates an issue labelled "bug" where they ask for a new feature, you have to go in there and change the label to "feature request". I'm not sure I understand why you think that matters in this discussion
That matters because it shows that there still is a need for the maintainer to go and make sure the labeling is correct. So having multiple top-level categories doesn't help with the maintenance burden.
I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.
> A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.
A healthy project can also close feature requests they don't want to implement. They can also choose to close every issue that isn't a bug report because they use different tools for feature planning and discussion. They can also choose to just automatically close every issue because they don't use github issues at all, but prefer other tools.
So, your issue with the current implementation is purely cosmetic / "semantic"? As in seeing there are 1000 "issues", when 999 of these are actually "improvement / feature requests"?
Because when you go in the issues tab, you then choose to only see "bugs", which will show you the one that needs handling, and you can ignore the 999 others.
"Cosmetic" and "semantic" aren't synonyms, saying "this project has 100 issues" has a different meaning from "there are 100 features which users want to see implemented".
But no, the wording isn't the only/main issue IMO, it's the lack of a clean separation between problems which should be fixed and non-problems which don't need to ever be resolved. It's a cognitive thing for maintainers, I believe mixing up those things contribute to burn-out through the purely psychological effects of being told by the UI that there are 100 things which need to be solved when there may in fact only be 5, it's a public perception thing when the stat that's prominently placed on the repo page is the number of open issues.
And yes, it's vague. It's not the technical lack of a good enough labelling and search system. And maybe different people react differently to this stuff, maybe some people have no trouble dealing with the lack of a clean separation. But given the fact that burn-out in open source is such a huge issue, maybe conflating the stuff which must be fixed and the stuff which doesn't have to be fixed isn't such a great idea.
I don't see how moving the categorization of "feature request" vs "bug" outside of labels helps anything. That must makes it harder to do the inevitable re-categorization that will always be required since the line between "feature request" and "bug" can get subjective and fuzzy depending on how one views the purpose / spec / scope of a project.
If all you are saying is that it is a UI issue to mix those two categories when you open the issues page for the first time, it is pretty easy to bookmark or link to a list of issues filtered by label.
I don't know what more I can say to make it clear that "there are workarounds or workflows which make it possible to separate bugs and feature requests" doesn't respond in any way to what I'm saying, so I'll just step out of the conversation now.
The question I was trying to ask you is: What do you see as a better way to separate bugs from feature requests and what makes that way better than the existing system?
If that doesn't relate to what you are saying in anyway... then I am really unclear on what you are trying to say
Perhaps other people may have another opinion but I'm afraid that most people seeing 200 issues think that the product is in the phase of intensive development so is not mature (what can be true) or that its development is stale (what also can be true). Their first thought isn't "it's a mature but still well-maintained product"...
> When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs.
That's just changing how GitHub presents the "issues." They could just as easily remove the global number display and simply display the count of each type of issue on the issues page.
> When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.
That's just a UX/UI concern. You can easily link to feature requests only.
None of these are "issues" related, but rather, just how it's displayed. Your concern is with the visuals.
Do you have any evidence that people assume that? Most popular projects have many issues, which don't seem to drive people away (e.g. React 900 issues, scikit-learn 1.5k).
You mean, until you manage your project...gasp. How horrible!
Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.
I don't understand what you are trying to say. Why is a build-up of feature requests a sign of neglect, if bugs are regularly fixed? Do you consider a build-up of unimplemented feature requests to reflect as poorly on a project as a build-up of unfixed bugs?
A build up of un-triage feature requests can be a sign of neglect or of maintainer overload (the later will probably lead to the former eventually), but you can't tell if that is the case just by looking at an issue count.
Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues are bunched together by default -- that filtering out the issues you don't care about takes any clicks at all -- contributes to that.
> the issue is with the lack of a clear separation
But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine.
I think it's a fine trade-off to have something generic, and let each project add whatever tags work for it.
I wouldn't be against renaming "issues" to something more "generic". Maybe "change requests"?
* Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.
* Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
Maybe both of those solutions are bad and a good UX designer (not a random commenter on HN who has thought about this for 2 minutes) can think of something better. Maybe both of those solutions are bad and there is no good solution and the current approach is the best possible. I don't know. Notably though, "there is no solution to the problem that's not worse than the problem itself" does not mean the same as "there is no problem".
> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this.
And then we also need to separate tab for discussions and questions since those are also very common use cases for issues.
> Have a category system, where the maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.
The only part of this that doesn't exist is a tab that links directly to the labels page, which does show the number open/closed issues per label
It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. I would agree that looking just at an open issue count is not the best way to assess the health of a project. I think you are better looking at open issues will un-merged pull requests and why they aren't merged. You can also look at a sample of open issues to see how organized and responsive the developers are and what types of bugs tend to be present. All of these require far more effort than just clicking over to the issues tab and then clicking into the labels page to see a breakdown of open issues by label. I would say that users that don't take the effort to do this basic research of before pulling in a dependency aren't the high value users that will help contribute to the value of the project.
> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues.
No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be intentionally misunderstanding me at this point.
Owners of a project have the ability to create clear separations between categories if they want. The 'issues with labels' structure allows each project to setup the categories and level of separation that matches their need. This is important because of the following:
The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "feature request" and there are also issues that don't fall cleanly into either category.
Examples:
1) A user opens an issues because a library doesn't work properly on platform X and fails with an error message. The developer of that library closes that issue with a "won't fix" because they don't support the platform. Is this a bug report or a feature request?
2) A user opens an issues because one of the dependencies of a library is no longer being developed so won't support moving to the new version of the language the library is written in. Is this a bug report or a feature request?
3) A project owner opens an issue because a new standard has been released that the library has to support because it is critical to it's ability to interoperate with other parts of the software ecosystem. This could well be much higher priority than many minor edge-case bugs, but is still new functionality.
The answers to these questions can, and should, vary from project to project and issue to issue depending on the larger context. An issue tracking system should be flexible enough to encompass these different needs.
I charitably assumed you were focused on "potential users quickly dismissing projects with too many open issues" since that at least provides a clear reason for why the current methods of categorizing issues isn't good. Since that assumption was incorrect, I still don't understand exactly what exactly your issue is with github issues.
I'm bringing up issues that have to be considered when creating an issue tracking system that serves the needs of a wide range of projects. You can choose to ignore those issues, but that doesn't mean they don't matter.
You've repeatedly conflated categorization of issues based on priority and categorization of issues based on relation to the spec. Just because something is a bug report doesn't mean it needs to be fixed and just because something is a new feature doesn't mean that it shouldn't prioritized over bugs. Ignoring this simply serves to keep the conversation running in circles.
The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything
> The forum was built to be a feature request tracker.
It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues."
Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.)
> It's used extensively for that purpose at Github
Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.
I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.
That's absolutely a valid point. However, if Github would have set something like this as a default, there would be a lot of people who would complain about it being too opinionated. Being open first with many options to customize and "lock down" is probably a good compromise.
That seems like a bad assumption. Even if there are 65 bugs, without taking a look at a sample of them you have no idea of the severity or relevance of those bugs.
Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.
A simple solution is to close all feature requests with a tag that lists is as a request, and a comment that explains that you may go through the requests some day when you don't have many bugs to fix. Or if a customer is willing to pay for an extra feature. Maybe even add a tag to indicate that this feature would be a good place for new contributors to start. Of course, you then get the same feature requests multiple times.
Note however that the scenario in the OP that leads to ruin starts with an external contributor contributing a feature. Someone other than the maintainer contributing the PR doesn't really solve the problem; the features still leads to complexity and maintanance burden that inevitably falls on the maintainers.
While I understand and agree to the solution you provide, I would dare to call it a workaround.
Since Github default culture is to use issues in a certain way, in which the maintainers are actually the bottleneck, most people will keep using it thinking it's the standard and correct way to do it.
Unrelated to the above, you mentioned the paid extra feature, I really wish to see this implemented in a source forge to see how it goes.
I've seen some projects that say almost exactly this: Feature requests will be closed. If you have a contribution or patch, I'll look at it. If you want to pay for something, contact me.
this sounds like an engineer fighting against reality. If there is a way to file bugs people will use it to file feature requests. It will be up to you to filter them. It doesn't matter what system you use
We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code.
I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.
Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Nobody has the insight to build in a modular way on top of that library or system, ironically despite being programmers! Sigh.
Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners of their new contribution and more. It does not always happen. Not all projects can achieve the scale and funding to do it properly but those are the ones that succeed.
Point to the ones that worked and there's the thousands of others that didn't, leaving the maintainers totally burned out. Turns out we're not born managers or project leaders. GitHub and others could do more to improve life for maintainers and users alike. I see sponsorships, but I don't see bounties! Where's the bounty programs? Reward the user for their contribution, reward the maintainer for their long term efforts. The platform needs to do more. Can't put all the pressure on the people using the platforms.
> Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners
This is well said. Maintainers need to grow their communities by allowing contributors to take ownership of components (this can be done with technical things like modular design that predicts future ways that things will be used, or by building good relationships with contributors), and they also need to have a clear vision for the things that their project is and is not.
It’s definitely a balance because if you are perceived as saying no too much and the community doesn’t understand or doesn’t accept your reasoning, then the project may stop growing and you’ll have less help to build the things you want to build.
And often there is already a modular system ready, but the person requesting a feature is either too lazy or doesn't know the system enough to use it (or sometimes even know it exists).
This seems especially true for drive-by requests where someone on a dev team has a feature they are required to implement in XYZcorp's application. They don't know the platform well, they see the feature isn't provided out of the box, so instead of doing much research, they just hop in the issue queue and request it.
Sometimes the modular system is very flexible and straightforward. Other times the system really is modular, but makes many assumptions which make little sense to and are even difficult to foresee by someone less familiar with the overall system. See all the years of discussion over libraries vs frameworks vs complete code ecosystems. If I have a three week deadline and it takes three months to come up to speed with your system's docs and code, I'm going to ask for something without an up-front PR before I take it on myself.
"Feature creep" -- the universal problem of almost every piece of hardware OR software or standards doc or government budget. Saying "no" is the hardest thing a manager ever does, because he or she usually hurts someone's feelings and maybe even their career. I suppose it has some similarity to the Tragedy of the Commons.
"All in all I'm being much more careful when researching dependencies and libraries before bringing them in." - As everyone should be. Folks are too blasé about importing bloated dependancies.
It's pretty easy to end up with one even if you tried to pick some popular and supported library, as they might not be a discerning as you in their dependencies
I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear.
Basically, this blog posts highlights why we should be paying for software libraries we use. All the downsides of proprietary code happens in open source. Open source projects don't add features you need, they can release a new version that has breaking changes and stop supporting the old version, they can just disappear, etc. However, the reality is, very rarely does popular proprietary just stop getting updated. While that happens in most somewhat popular open-source libraries. You can go to most mature open-source libraries and you'll see that the commit activity is down from when the project started. Many will say that's because it's feature complete. However, if you look at the open issues you'll see lots of activity. Often the issue is that the original maintainer has lost interest, be it because life - love affairs, children, sickness, etc, or that they've got a new hobby - arts, music, new tech, etc. I don't blame these maintainers, it's free and they owe me nothing. But at the same time I blame the industry for making it so common to build on these libraries that literally promise nothing for production code that you'll be extremely hard press to find a job that doesn't require you to build on top of FOSS.
My prefered approach which I'm taking with my SaaS Boilerplate/General functionality bundle is use source-available license. Namely BSL - Business Source License with an additional grant that if you make less than $5k per month you don't need to pay. This allows the best of both worlds in my opinion. The ability to test it out, see it, use it for free in certain scenarios while making people who make money from it pay for it's maintenance. The full details of this license and approach can be read in the FAQ https://github.com/getparthenon/parthenon#faq
> I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear.
I have no problems with open source maintainers charging for software, but I think the bigger problem is people having incorrect expectations of the open source model.
The main point of the open source is that if the software isn't doing what you need, then you can fix it yourself. Developers often act so helpless when it comes to dealing with bugs or missing features in their open source dependencies. Obviously that involves work, as you can't rely on some third party to maintain the software (or at least your fork) for you. On the other hand, you can't always rely on the vendor of proprietary software either. But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.
In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.
As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".
> But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.
Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature. Very rarely will a company say there is no price high enough for them to add a feature. This is so common that the pricing is pretty much standardised, nearly every company I've worked for when adding features for customers charge the same 1 thousand euros per developer day of work.
Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.
> In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.
The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.
> As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".
Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.
> Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork. With third-party corporate code, you can nearly always pay for them to add a feature.
You can also almost always pay for someone to maintain a custom fork for you, if you don't want to do it yourself.
> Here comes the issue, what if it can't get incorporated upstream? You end up with your own custom fork.
I think I was unclear. My point was not that you could merge your own fork into the upstream, it's that you could merge any changes from upstream into your own fork. My point is that yes, you are maintaining your own fork, and while maintaining a fork is work, it is a valuable option that people forget about and yet is one of the key motivations behind open source to begin with.
> With third-party corporate code, you can nearly always pay for them to add a feature.
I have seen developers refuse to fix bugs in software that costs literally millions of USD in licensing. But beyond that, there is always the possibility that the software ends up with no maintainer, and even for the source code to be lost completely. Open source hedges against that risk.
> Source available via BSL still allows for the modification of the code to customise it. So that benefit is still there.
That's good. You'll see no objections from me. I don't really care much personally how people choose to license their software. While I have mentioned some of the benefits of open source, my point is not that "open source is better" but it's that the problems people have with open source come more from bad expectations of how that model should work in the marketplace rather than a problem with open source itself.
> The real cost of software is maintaince. Updating it to keep it working with newer versions of x,y,z. etc.
There is no inherent obligation to maintain projects you have released as open source. The code is already out there. If people want to modify it to fix bugs or add features, they are welcome to do so. They can even share their changes with the world! The only maintenance costs in open source are those costs the maintainers choose to take on. If a maintainer chooses to update their software, then each of those versions is a release of open source code, and the guideline still applies. If you make a change in an open source project, the cost of that change should already be accounted for before you release it.
> Not all projects are considered popular even though they're widely used. You may end up using a very rare but very important library to do something that not many people are doing. Not everything is sexy, especially when it comes to libraries you need for work.
That's true, but doesn't undermine my point. The point is that the pursuit of status plays a role in why people contribute to open source (and why they put up with onerous user requests). They (consciously or not) hope that by contributing they will be seen as cool and smart by others (or at least others within a given clique).
The problem with paid proprietary code is that it almost inevitably devolves into a bloated mess of haphazard features being tacked on year after year by contractors who don't care about how hard it is to maintain, and don't even care if it works well because they don't need the code themselves, and the people buying the code don't use it, because they're buying it on behalf of a company and the people who actually use it just have to suffer through it.
I think the one thing that would help open source more than anything else is if we outlawed contracts where the employer owns all copywritable material created by the employee.
Ah, the author has found the infamous (in my opinion, much much worse than average) state of React Native packages and libraries. For some reason it seems especially React Native packages have a horrible bug rate, low maintenance frequency, and worse... (as an example of what I've seen more than once now, critical bugs are introduced in between minor version changes!) Perhaps it's the ecosystem itself (needing to have native code AND javascript code for BOTH iOS and Android), or the pace of React Native changes itself, but I'm not sure.
Anyway, wholeheartedly agree with the author that one should audit and research packages very carefully before deciding to add them to your codebase. And in React Native, small, "do one thing and do it right" packages would be an unbelievable breath of fresh air.
It's almost as if not getting paid for the work confers zero reasons to fix bugs that don't affect the package author(s) themselves? Weird how that seems to be the case, if only there was some way that people who made money off open source could help get issues fixed by, I don't know, offering something in return?
(React-Native's ecosystem isn't even remotely worse than average, you're just looking at it in absolute terms: the more popular a framework is, the more people will create tooling around it, and so the more stale projects you run into. If you rely on packages not going stale, and your company literally makes money thanks to them, be that directly or by helping you put out your name so you can make those dollars, have an open source budget, and use it)
i believe that software design is really hard. it seems appropriate to mention "conceptual integrity" which is a term i believe was coined by the (recently) late great fred brooks. his book "the design of design" talks about it a lot and i really found the discussion helpful. here is a very brief summary from his earlier book: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept...
sometimes saying no is the right thing to do.
as an aside, i find it a little distasteful that the author of this blog post chose to call projects out by name. these people are putting their efforts out for free and they are, to my eyes, taking flak for doing so.
I maintain python sysrsync package and my idea at first was to validate files before syncing with systems rsync. That was rightly pointed out by users as bloat and I took it off in a major release.
Similarly there is a feature request that although justified for the sake of symmetry (I support exclude in the API but not include) I am reluctant to add it because I really don't want it to have more features, when there is a way to access all rsync flags using options argument.
It seems like there's an implicit theory here: if one maintainer says no, then some other competent maintainer will pop up to handle the excluded bit of functionality in a separate library. Why would that be the case? And what about the alternative of getting that person to participate in expanding the existing project?
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.
Most projects developed this way die of development resources starvation. Once you have added all those features you will face all the consequences of developing a complex system -- difficulty to get anything done, new devs requiring substantial amount of time to get started, people getting discouraged quickly, etc. As you add complexity, the ways users use your platform will grow exponentially -- potentially causing an explosion of bugs.
I don't mean users using your platform in many different ways is bad, the question is "Can you support it?"
If you run into developer resource starvation users will find that you are making no progress and will find an alternative and this will make your project even less enticing for contributors. This is how a project dies.
If you are single developer and want to do something useful for community your best shot is to make something simple and add things judiciously.
So how do large open source projects survive and how are they different? The issue is that when it comes to contributors, relatively few large projects receive most of the contributions. Everybody wants to contribute to something well known, high profile, used by a lot of people. Not many developers want to make it their mission to support a useful but an obscure plugin to something else.
I'd say precedent is against you here. There's many examples of widely used open source projects that don't get lots of free maintenance effort.
Maintaining something well is hard and requires commitment, you can't just crowd source it with people dipping in and out with the occasional fix and new feature. Being careful about what PRs you accept, especially when it's a big new feature is crucial to the health of an open source project and the mental health of its maintainers.
Making this will exponentially increase the glue code required to tie everything together.
So, while new developers fix the features, they'll also need to fix that glue layer too, making the work twice or thrice as big. Also things will also even get more complicated as long as things get added into the mix.
This is why UNIX philosophy is very important. Keeps software simple, compact and much more easier to maintain.
It can work but you have to have a vision on how to integrate extra features, not just shove them into the codebase.
Consistent plugin API allowing to plug-in code in various parts of the app takes a bunch of effort but now you're magically separated by a wall of code from the contributors, as you're never a blocker for someone's else effort to add features, and the stuff you don't want to maintain can land in contrib repo
For all the negative responses you get, there are a bunch of open source projects that work kinda like this.
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.
This may work as a strategy for a VC-backed startup, where you just throw money into resources to create the largest possible gravity for your product, and solve the technical debt by growing your team once you have a critical (paying) userbase.
But how would this work when there's no money to throw around, your product is free and every contributor is actually a volunteer who still needs to earn his living elsewhere?
The other factor to consider is how features complicate unrelated maintenance and new development. If you accept new features which are affect other parts of the codebase, you might find that the things you are finding volunteers to work are made harder due to something most people don’t use and thus aren’t jumping to spend time supporting.
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.
Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)
This works best if you don’t care about security and aren’t planning to stick around at the same job. If that’s not the case, there is a real cost to a regular stream of updates required for features you don’t use - especially when there’s some kind of major upgrade like Node has had a couple of times which forces everything to update, and you get some period where not all of those dependencies have shipped updates or backwards-incompatible changes are required, and you might have to help get changes made upstream or fork something.
Better hope no security exploits are found when you’re in the middle of that process…
These things you list are not something I care about if I want to get stuff done. Caring about what node version I run is also a non-issue. I have 6 different versions of Node already because of this issue, which is not mutual exclusive to big packages.
I wasn't saying that Node itself is a security problem but rather that the community is biased towards rapid upgrades, trading long-term API stability for the ability to use new things quickly. That's a valid trade-off which a lot of people have enjoyed but it does mean that you need to think about whether you have the resources to keep surfing that wave when adding new dependencies. It does seem like the community is reconsidering that balance, too, after years of things like leftpad or worse have been highlighting how exposed most projects are to a single compromised maintainer.
Basically the same lesson can applied for saying no to feature requests from clients on your SaaS product; saying yes commits you to ongoing support, and you need to consider if it's worth it, particularly consider if said client is trying to outsource what should be bespoke work on their side, to you.
I wonder if having some sort of dependency scanner giving more upfront visibility would help clear things up. Then you'd be able to get a sense of what the composition of issues might look like. Seems like there's so many scanners out there that something must solve this.
I'm planning to use this model when I eventually launch my company. What's unfortunate is I need to handle payments myself because GitHub doesn't have a payments feature for maintainers to leverage.
Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB.
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":
I understand what you say and the appeal for it. However, I have to admit that one of the reasons I like Golang over Python (Although I develop in both frequently and enjoy them) is because of the language mentality of libraries over frameworks. I prefer many explicit different dependencies glued together from one's own logic than a batteries included Framework where big part of the magic happens under the hood and ways of doing things must follow an specific path that does not always applies for your specific business case. I think this approach gives a better flexibility (and can cause annoying paralysis by decision too).
Flask is split up into a few Pallets projects - Flask, Werkzeug, Markupsafe, Click, itsdangerous, Jinja2 - but they're all from the same stable group. This split makes them more useful as independent libraries, rather than one big framework.
Ditto two more (Alembic and SQLAlchemy) are also from a very stable group. It would be nice if Alembic used Jinja2 instead of Mako, of course, but it's a dev-time dependency and so it's lower risk in my opinion.
I agree that at the thing Django does (forms + a SQL database) it does it with fewer dependencies than Flask. But that doesn't mean Flask has loads of dependencies; it has an appropriate number for the task you're doing. I was more comparing Flask to actual dependency soup ecosystems[0].
Ditto. I liked Flask years ago but unless you’re doing very contained microservices it always ends up feeling like you’re building your own framework. This isn’t a slam on Flask but rather, I think, a reminder that we’re so prone to think about the fun of being able to customize everything without thinking about the maintenance trade-offs.
I believe a minimalistic server framework (Flask) is an unfair comparison to what the author is complaining about, namely packages that need to integrate into an entire front end framework and ecosystem (React Native). Handling requests (Flask's primary use case) is but a small fraction, and addition to, all of the other things you need to implement and consider on devices that would run React Native.
Examples: camera roll and / or camera integration, contact listing, deep linking _into_ the app, linking _out of_ the app, foreground or background push notification display (and subsequent routing on press), the list goes on and on. IMO, native development, even if you choose to go Kotlin / Swift path instead of react native, is extremely complex.
To be brutally honest, I too can fire up a linux box or container, install flask, and have my simple REST server up in a matter of minutes. The same cannot be said for all the example native features listed above.
"Sorely missing" really depends.. for you, a particular user, maybe. But e.g. not having quote tweets in Mastodon was a very deliberate decision (I don't have the issue at hand) not to go in the direction of Twitter here. Quote tweets have their downsides too. This was about keeping project direction and doing things the Mastodon way.
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.