pub-dev
pub-dev copied to clipboard
dart-lang
Mark commercial packages
In a recent user study, some participants want to see commercial packages, because it signals high quality to developers who are willing to use commercial products.
Or is this separate from the licensing, and more about support-level?
Packages could have a flag in the admin tab: "commercial support available".
I think this is separate from licensing. I think a flag and an associated filter option will work, like the null safety flag and filter.
One thing I would be concerned about with this is indirectly reducing the confidence in non-commercial packages. For example, neither provider nor riverpod are commercial, but since there is no commercial package in the same category, it won't affect them. But, for example, ObjectBox is a commercial database package, which might subconsciously signal that it's better than the alternatives (eg. Hive) - same with the mapping packages: flutter_map vs Mapbox vs Google Maps (~~flutter_map is objectively better :D~~).
Additionally, how would the validity of this be certified: the Mapbox maps package is/was maintained by an unrelated team, but targeted specifically Mapbox - is that commercial? And with the relatively new official Mapbox package, would that change the status of the other one?
@JaffaKetchup Denigrating other developers' work is not a great way to make your point.
Sorry, which am I criticising? I don't mean to criticise anything? (If it's the mapping part, I'm a maintainer of FM and trying to make a joke with a point - neither FM or Google Maps is not objectively better than the other/alternatives, but Google Maps might appear better if given a special label.)
All I'm trying to say is that just because a package is commercially maintained/supported, doesn't necessarily make it 'better' than a package that isn't. Being commercial doesn't necessarily imply being high quality. Some users may be given this potentially false perception, and when trying to encourage maintainers to maintain their projects, artificially taking users away doesn't help. The reverse is also true.
@JaffaKetchup: Apparently there are teams and companies out there who will only depend on commercially supported packages. It is not because they attach different quality or meaning to it, rather their business continuity model is based on the payed support: they want to have response times or whatever SLA the support contract provides. They want to make sure that there is a person they can contact to in regular business hours that they can count on to resolve their issues on a schedule that they can plan for. Community support may provide similar response times, but everybody has time off, emergencies or just way too many different work. Commercial support means that the developers of the package are planning to handle their users'/clients' requests in a timely manner, accounting for such possibilities too.
Other times it is just the willingness / preference to pay for something so it will be maintained on an ongoing basis.
In any case, I think it is useful for package authors to be able to indicate that such support is available through them, and for users to filter the package space for such packages. I cannot really tell if this could be misperceived in ways you have described, but if you have specific suggestions for the implementation that could alleviate such fears, please share them.
Ah, I see. If this is just to indicate 'commercial support availability', then I don't particularly see an issue with that. Just labelling 'commercial package' without qualification might have the problem I said.
EDIT: just realised an intermediate comment above said exactly this, which is slightly different to the initial issue. Sorry I didn't see it!
What we can differentiate on are (a) the license (whether it is a traditional open source license or some custom version) and (b) the support availability (present or unknown/absent). I'm not sure that the phrase "commercial package" is wrong here though, but focusing on support may be better to dodge the misunderstanding.
If it's the mapping part, I'm a maintainer of FM and trying to make a joke with a point
And my point is that making a joke that is at the expense of other people maintaining packages is not a good approach. It is possible to explain how labelling could, if not handled carefully, make some developers feel that their work is being devalued in some way without demonstrating the concept by devaluing the work of other developers.
@isoos Definitely agree with making the license more obvious. Can have differentiators for permissive, copyleft, and unknown? But I wouldn't want to penalise for copyleft or unknown.
In terms of support, also agreed, maybe a similar thing: "best ability", "+ as a paid service", unknown? Of course the naming might use some work.
The thing I want to differentiate is the situation ObjectBox, Google Maps Flutter, and Mapbox Maps Flutter are in. IMO they are all "commercial packages" - they are maintained by companies with the sole purpose of generating revenue for themselves (maybe with the exception of ObjectBox, but they use other strategies). They are all open source (to a point), but all commercially-aimed IYSWIM: they all are designed to generate revenue. As far as I know, none of them offers commercial support in any capacity (maybe ObjectBox does, but it's unclear). What would be done with packages like these?
And I don't have an issue with marking as commercial (or whatever variation), just so long as it's clear it doesn't imply high quality. The commercial packages may offer commercial support as a service, but that doesn't make them high quality for those not using them with that paid service.
@stuartmorgan The joke wasn't supposed to devalue anyone/anything, I apologise.