Publicizing MacPorts

[Andrew Janke]

On 4/19/21 3:54 PM, Craig Treleaven wrote:
>
>> On Apr 19, 2021, at 2:51 PM, Jason Liu <jasonliu at umich.edu
>> <mailto:jasonliu at umich.edu>> wrote:
>>
>> On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven <ctreleaven at cogeco.ca
>> <mailto:ctreleaven at cogeco.ca>> wrote:
>>
>>     Also, why should we consider that MacPorts is in competition with
>>     Homebrew?  Both MacPorts and Homebrew seem to have a sufficient
>>     number of contributors to keep going for the foreseeable future. 
>>     Nether packaging system has to "win" nor does the other have to
>>     "lose".  The projects do have differing philosophies that may
>>     make one more suitable than the other for particular users.
>>
>>
>> Although this is a nice sentiment, I believe the reality is that
>> MacPorts is in fact in competition with Homebrew. And not just
>> Homebrew, but with other package managers as well, such as Munki, and
>> even to some extent other deployment products such as Jamf/Casper and
>> Jenkins. My belief is that the total number of systems running macOS
>> as its operating system is the entire "pie" of systems that could
>> potentially use one of these macOS package managers. In addition, the
>> vast majority of users will only use one package management product,
>> hence my opinion of why it's a pie with a limited number of potential
>> users that gets divided up. The possible exception to only using one
>> product per machine might be, say, in an enterprise setting (you can
>> read my personal anecdote below for an example).
>>
>> In addition, it has traditionally been the case that package
>> management systems say on their websites that installing multiple
>> package managers on one machine can cause problems... e.g. MacPorts
>> doesn't work well with Fink and Homebrew, Homebrew doesn't work well
>> with Fink and MacPorts, etc. People on this mailing list are tech
>> savvy enough to deal with the potential conflicts that might occur
>> regarding environment variables, $PATH order, etc. but the vast
>> majority of users won't be, and thus would stick to using only one
>> package manager. If one product "wins" by getting installed on a
>> particular system, then the others "lose”.
>>
>
> I wasn’t trying to suggest that a user should install multiple package
> managers.
>
> MacPorts needs contributors and maintainers to go forward.  We don’t
> _need_ users!  It is the same amount of work to create or update a
> package regardless of the number of users.  Several of the packages I
> maintain have very few reported users…sometimes only me.  
>
> As long has we have a decent volume of people contributing to MacPorts
> the project will continue.  As a port maintainer, it is gratifying to
> think that my work may be benefiting others.  It is not that important
> whether it is 10 people or 10,000.  I think that many of our
> maintainers do so because they need the ports that they are working
> on.  IOW, they’d do so even if there were no other users.  Obviously,
> several of our most prolific maintainers have different motivations.
That would be my concern here. Keep the project alive with an active
maintainer community. But I'm a bit different; I want to do work on
projects that are visible and actively helping users; that's (partially)
how I decide where to put my time.
> To be cynical, I think Homebrew users are more commonly command line
> newbies and therefore probably generate a high volume of simple and
> repetitive questions.   AKA ’support desk hell’!  Perhaps we are
> fortunate that MacPorts users tend to be a little more savvy.  ;)
Speaking as a former Homebrew core maintainer – not actually the case!
We got almost no 101-level support requests; Google and StackOverflow
take care of those just fine. The majority of requests coming in to
Homebrew are actually PRs to bump versions on packages (a significant
number of Homebrew users like to be contributors too, and there's almost
a competition to get to new package releases first), and most of the
rest are semi-obscure build and linkage problems, problems with macOS's
System Integrity Protection stuff, or legit workflow issues with the tools.

Though I agree that MacPorts is definitely the "pro" product in this
area, so I expect its users are even more savvy.

Cheers,
Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20210420/fc93209a/attachment.htm>