<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><blockquote type="cite"><span style="background-color: rgb(255, 255, 255);">MacPorts faces is that it has an image of being “old and dead”, especially compared to vibrant alternatives such as Homebrew.</span></blockquote><br></div><div dir="ltr">This is the issue. If you don’t tell your own story, others will. MacPorts is not telling its own story.</div><div dir="ltr"><br></div><div dir="ltr">Saagar’s consequent suggestions are also excellent: announcements/social media, statistics, website, in my view in that order of importance.</div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Apr 21, 2021, at 08:01, Saagar Jha <saagar@saagarjha.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">I’m not a MacPorts core maintainer or anything, nor am I a PR expert, but (for various reasons) I happen to interact with a lot of users who are curious about macOS package managers. Here’s a couple of takeaways I have from those conversations, as well as my thoughts on what MacPorts could do in light of them.<div class=""><br class=""></div><div class="">The biggest issue that I think MacPorts faces is that it has an image of being “old and dead”, especially compared to vibrant alternatives such as Homebrew. Of course, much of the response I get to MacPorts is “I’ve never heard of it” but even from the people who know what it is I hear a lot of “I used that several years ago, but then I switched package managers…wait, it’s still around?” There are a couple of other undesirable impressions: that MacPorts is the place that’s missing packages, or has ancient copies of them, or that MacPorts compiles everything from source (there was a thread on this list just recently on this topic). Obviously these are not quite true, nor are they things that one would want associated with MacPorts. I think the solution to this is two-pronged.</div><div class=""><br class=""></div><div class="">The first angle here is one of advocacy: MacPorts is obviously *not* dead, but nobody knows about it, because there is nothing to tell them about it. I think maintaining even a minimal social media presence would do much here. MacPorts should capitalize on its strengths and announce them when appropriate. This doesn’t have to be a lot of effort (and I would of course be happy to help with it, if that would be useful)–it’s things like spending an hour on a blog post with details of what’s in a new release, or posting relevant updates on Twitter when appropriate. Uncompromising M1 support has been mentioned in this thread already as a major plus for MacPorts, and I fully agree; nothing would have sold “this package manager is alive and well” better than showing how well MacPorts supported Apple silicon from the get-go. As another datapoint, compare <a href="https://news.ycombinator.com/from?site=brew.sh" class="">https://news.ycombinator.com/from?site=brew.sh</a> to <a href="https://news.ycombinator.com/from?site=macports.org" class="">https://news.ycombinator.com/from?site=macports.org</a>; and keep in mind that Hacker News is one of the few places on the internet where a Homebrew mention is often followed by favorable one for MacPorts. There’s probably some new OSes and hardware dropping later this year, perhaps it might be wise to highlight that MacPorts runs on them when they come out.</div><div class=""><br class=""></div><div class="">The other part is technical: MacPorts actually needs to live up to what we are trying to sell it as. If the website has pages that haven’t been restyled since 2008, people are going to think that nobody has touched them since then, which isn’t how you want to present yourself if you’re an actively maintained project. (I know there has been work in the past in this area–I guess we just need to build on it.) If you try to install a package and the project tells you to use Homebrew to get it on macOS, or you install it in MacPorts and it’s a version from four years ago, then I think it is natural to end up with the idea that MacPorts doesn’t have packages you want. Where possible, I think we should track statistics of which of our packages livecheck as up-to-date, or how good our coverage is of things from other package managers. I know this is work and perhaps there is not enough manpower to handle it, but perhaps they can help inform what should be focused on.</div><div class=""><br class=""></div><div class="">One final thing: I think certain strategies might be counterproductive or unhelpful at this stage. Contacting the press is one way to get your message out, but it’s a fair bit of work, and fairly rare among software projects regardless. Other package managers get publicity just fine without it, and frankly if you’re already doing your publicity job well people will write about your thing of their own accord. Also, treating Homebrew and other package managers as “competition” where they have to lose is, IMO, an unhealthy way of looking at the situation. Homebrew caters to many developers and does a very good job at it, and I honestly believe that many of them would not enjoy using MacPorts. The right way to frame this, in my mind, is to recognize that Homebrew et al. have their own policies and ways of doing things, and MacPorts has its own. I don’t see us as trying to “steal” users away from other package managers–instead, the goal should be to identify those who are unhappy with them and help them realize that there are alternatives that might better suit their needs. For Homebrew at least I honestly believe that they would be glad to send their underserved users our way. We just need to work to make them aware of this choice.</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><div class="">
Saagar Jha
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2021, at 12:03, Rainer Müller <<a href="mailto:raimue@macports.org" class="">raimue@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 20/04/2021 12.40, Steven Smith wrote:<br class=""><blockquote type="cite" class="">That’s begging the question of an effective communications strategy. A distributed model of random volunteers is perfect for aggregating git commits. It’s highly ineffective at communicating important news from that organization.<br class="">If MacPorts wants to communicate better, it must post important announcements like “MacPorts supports the new Apple silicon M1” at a MacPorts website, and someone with a <a href="http://macports.org" class="">macports.org</a> address must send emails to a few tech reporters that say “look at this please.”<br class=""></blockquote><br class="">If you pledge to handle this kind of marketing, I would have no problem to hand out an @macports.org address for that. By the way, having our own mail domain is not that common for open source projects. Most projects hosted on services such as GitHub/GitLab/etc. will never have that. I really do not think it is of that much significance.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">We would be grateful if more users/contributors could join the boat<br class="">and actively help in areas where they feel that they could contribute<br class="">to the project (in one way or another).<br class=""></blockquote>That’s precisely why a more effective and realistic commutations strategy is desirable.<br class=""></blockquote><br class="">I don't disagree. But it needs at least one person invested enough to start it and then some more to follow-through with it.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">If someone is willing to step up and write blog posts, articles<br class="">(potentially based on a few rounds of questions/answers/document<br class="">revisions), etc., that would certainly be more than welcome.<br class=""></blockquote>I’d wager that many people would write these, but the channel and infrastructure for this do not now exist: no MacPorts News/Announcements page, no blog page, a somnambulant Twitter feed, <a href="https://twitter.com/macports" class="">https://twitter.com/macports</a>, and no peer review control mechanism. This can be accomplished by providing such tools to divide-and-conquer, with an open peer review mechanism for contributors without commit authority.<br class=""></blockquote><br class="">We have the news section on the website [1]. Posts can be submitted with pull requests to the corresponding repository [2]. At the moment, it is only in use for release announcements that are also posted on macports-announce [3]. I don't think anyone would object against posting more.<br class=""><br class="">I know the Twitter account is not as active as it could be. I personally do not find the time to post there regularly. I can grant you access to the account through TweetDeck if you want to make it more active. There is a list of people with access on the SocialMedia wiki page [4]. Currently the only rule is that tweets should have a signature by their author.<br class=""><br class="">As you can see, some infrastructure exists. It needs community members to step up and provide content to fill these channels.<br class=""><br class="">Rainer<br class=""><br class="">[1] <a href="https://www.macports.org/news/" class="">https://www.macports.org/news/</a><br class="">[2] <a href="https://github.com/macports/macports.github.io" class="">https://github.com/macports/macports.github.io</a><br class="">[3] <a href="https://lists.macports.org/pipermail/macports-announce/" class="">https://lists.macports.org/pipermail/macports-announce/</a><br class="">[4] <a href="https://trac.macports.org/wiki/SocialMedia" class="">https://trac.macports.org/wiki/SocialMedia</a><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></body></html>