
Goodbye Mac OS Forge, hello GitHub - sashk
https://lists.macosforge.org/pipermail/macports-dev/2016-August/033405.html
======
JD557
> Over the years, several developers have asked why we're not on GitHub. The
> perception is that "everybody" is on GitHub, and some developers don't take
> your project seriously if it's not on GitHub.

This is the sad truth. It doesn't matter anymore if Bitbucket/Gitlab/etc. are
better than GitHub: The social pressure for open source projects to move to
GitHub is so high that the alternatives don't even stand a chance.

Maybe a meta-search engine for open source projects could help the
competition, but if all projects are on GitHub, who would use such a search
engine?

P.S.: I actually like GitHub, I'm just sad that all cool changes that GitLab
has made recently will end up being mostly ignored by the OSS community. Even
if they fixed their speed problem (which I think is their biggest downside
compared to GitHub), no project would move there because "everybody is on
GitHub".

~~~
cm3
Given that Gitlab provides a superset of Github's features, it's possible to
operate on both platforms, while clearly indicating where the primary location
is. Gitlab has built-in CI, so that can be used exclusively there, and it will
be one incentive for users to come to a project's Gitlab instance instead.

Personally, I like hosting a repository on Github plus Gitlab for availability
reasons, but if Github would finally allow disabling pull requests as well,
one could easily make Github a read-only mirror.

In light of non-existence of project patch, ticket, release, wiki
interoperability protocols, we will either adopt more of FossilSCM's features
into git addons (like git-appraise) or someone will write adapters.

The most concerning aspect of all of this is that projects that have access to
hosted FOSS servers which are fast and under (semi-)direct control give in to
peer pressure and move to a closed platform like Github.

If, say, Freedesktop.org would run a Gitlab instance, it would prevent the
move to Github. I cannot be the first one to think of that.

~~~
benologist
We should just reject github and watch how fast they roll out a self-hosted
version almost nobody wants to host themselves.

Today's open source alternatives will be followed by endless more experiments
in building a better github, hard to imagine someone "never" nailing it let
alone "never" being handed it on a platter because the first website in
history annoyed too many of their users at once at just the right time.

Going open source wouldn't have saved digg after everyone decided to break
their old routine. They had nearly identical open source competitors with
variations of their own interface all along, even direct clones.

None of their customers ever needed it or benefited from it being a
proprietary service either. It's probably a lot more important to Gitlab than
Github.

~~~
cm3
It's not primarily about the platform being open source, but relying on a
SPOF. It's dangerous and empowers Github to pull all kinds of stuff while they
have the marketshare. Today's github may not do shady things, but tomorrows
can. It's irresponsible of us to put all our eggs in one basket. At the very
least, helping them to be the place where 99% of projects are hosted will
allow github to ignore complaints.

In fact, it's a good thing Gitlab is not a pure open source project, because
there's leadership involved and business interests with real life problems to
address. So, the chances of "endless experiments" is low. Sure, if Gitlab was
fully open while keeping project leadership and all, it would be even better.

~~~
benologist
The only reason it's a SPOF is they don't allow anyone to read/run/modify
their code... that's what open source covers.

I think the problem is we conflate selling the only access to our code with
selling access to it. If you need online hosting for your project the
alternatives are almost immutable - somebody's server running project
management software.

No matter what Github does developers are trending towards using open source
tools to the extent Microsoft's porting their company to Linux right in front
of our faces...

~~~
benologist
Belated edit I wasn't criticising Gitlab, I meant it's probably more important
to Gitlab _that Github be proprietary_.

------
falcolas
With all of the - I'd call them shenanigans, but I'm sure they're justifiable
features [0] to someone - with homebrew, it may be time to take a closer look
at macports as a replacement. Glad to see the project not only alive, but
evolving with the community.

[0] Like automatically running `brew update` with every brew command run. I
was literally wondering if my computer had frozen up again when I saw that it
had done a full update (which involves not only patching the brew code, but
updating its source repos) before installing a pre-compiled version of tmux.

~~~
ploxiln
Yeah, that one surprised me too recently. But most of the junk _can_ be
disabled. My current settings:

    
    
      $ env | grep HOMEBREW
      HOMEBREW_BUILD_FROM_SOURCE=1
      HOMEBREW_NO_AUTO_UPDATE=1
      HOMEBREW_NO_EMOJI=1

~~~
jordigh
Can you disable all of its cutesy names? Bottles for binaries, cellar for
package path, taps for 3rd party repos, recipe (or formula? I forget) for
build scripts, cask for a REPL... I honestly got a bit confused at first by
what all of these things meant.

~~~
CookieMon
This habbit of programmers to name things with puns instead of descriptively
drives me batty. WiX is bad, but Homebrew is on a whole new level.

Each time I use a mac I have to relearn what a tap represents vs cask vs brew
vs celler etc. But hey, aren't they clever with words!

~~~
Washuu
Those clever words immediately made sense to me for their inherent meanings
the first time I saw them. So they are actually quite useful in their
pairings.

~~~
rbanffy
I love puns just like everyone else, but when you have a word that precisely
describes the thing you have, why not use it instead of using a clever
metaphor?

~~~
Terretta
Like programs for Pages, Numbers, Keynote, Photos, Notes...?

~~~
sitkack
Word! The picture you paint, drives a powerful point.

------
rubyn00bie
I am sincerely curious when I ask this, please don't see it as flame bait--
what/who uses Macports still instead of Homebrew (or Nix)?

Is it for legacy systems? Or unusual requirements? Habit?

Edit for reasoning: I'm curious because who knows-- maybe I'm missing
something really cool or jumped ship to Homebrew years ago too hastily?

Edit #2: Just wanted to say thanks to the folks who have replied below! I'm
definitely a bit more curious about macports again.

~~~
peatfreak
I still use MacPorts because it's actually a proper package management system.
Homebrew is not, and its limitations started to show a long time ago. The
obnoxious assertion that Homebrew should take complete control of /usr/local
AND be able to install in there as an _unprivileged user_ is utterly
ridiculous. It's just some nonsense that the author cooked up in his own head,
contradicting a long history of convention regarding the use of /usr/local.

The maintainers of packages are _supposed_ to port their software to the
relevant platform, that's their job, and yes sometimes this takes some work,
whereas Homebrew seems to assume that ./configure; make; make install should
flawlessly work out of the box for pretty much anything (this is not true).
The fact that they actively discourage even trying to install outside of
/usr/local is simply laziness (and not in a good way). This is a foolish and
naive approach, and pursuing this idealistic, reductive approach for
"simplicitly" breaks down very, very quickly. MacPorts is a well behaved,
self-contained system, and a well designed one at that. Homebrew just dumps
everything into a system directory that it really shouldn't have exclusive
rights to in the first place (/usr/local).

Moreover, there is nothing wrong with installing extra compilers, libraries,
etc, under /opt/local and having them run alongside the system libraries. Lots
of systems have provisions for doing something like this.

Also, using version control systems as distribution and deployment systems is
a horrible anti-pattern and I really, really wish people would stop doing
this.

Homebrew's documentation is terrible. Its terminology is facile and stupid in
the way it analogizes everything with beer.

~~~
pbiggar
> "it's actually a proper package management solution", "homebrew is not",
> "its limitations started to show a long time ago", "is utterly ridiculous",
> "its just some nonsense", "are supposed to port their software", "that's
> their job", "(that is not true)", "is simply laziness", "foolish and naive",
> "breaks down very very quickly", "is a horrible anti-pattern", "facile and
> stupid".

I downvoted you. You assert a massive bunch of things with no evidence. A
reasonable person could disagree with every single one of them (I do). While I
could imagine your reasons for believing some (most?) of these, I would simply
be arguing against the strawman I constructed. By providing actual evidence
("why do you believe this to be the case"), you would allow us have a
constructive discussion on your points. Instead, you give us bile.

~~~
clhodapp
Today, Homebrew does have some _major_ shortcomings. The biggest one that
comes to mind for me is the fact that it only seems to consider the
dependencies of a package during its initial installation. That is, if A
depends on B, installing A _will_ trigger an install of B. However, after
that, Homebrew will happily let you uninstall B (thus breaking A) without so
much as a warning. Less critically, it doesn't track the fact that it only
installed B for the purpose of making A work, so it can't help you clean up
the left-behind-dependency cruft from the stuff you've since removed.

~~~
mh-
I don't disagree with your assertion about the state of Homebrew, but I wanted
to point out the `leaves` subcommand.

    
    
      brew leaves:
          Show installed formulae that are not dependencies of another installed formula.
    

I'm not sure if it persists this state or simply calculates it on-the-fly by
enumerating your installed formulae. But it does seem like the same data or
functionality could be used to prevent your uninstalled-deps scenario.

~~~
clhodapp
Hmm... Interesting. I don't think that "brew leaves" truly solves the problem,
though, since the list it generates will include explicitly-installed leaves
in addition to no-longer-needed dependencies. It can help narrow the list of
potential candidates for removal, though, which is nice.

------
kchoudhu
The problems addressed by Homebrew, Macports and the like have all been solved
in a cross-platform manner by the fine folks working on pkgsrc.

Sane defaults, respect for system security settings, and a general lack of
bullshit. As a *BSD refugee on Mac OS X, it feels like a slice of home every
time I need to install software.

~~~
athenot
It's my understanding MacPorts came from the same BSD Port system and keeps
the same philosophy. How does pkgsrc differ?

~~~
kchoudhu
Prior discussion:
[https://news.ycombinator.com/item?id=9407119](https://news.ycombinator.com/item?id=9407119)

Because of the cross-platform focus of the NetBSD developers, I can replicate
my package installation workflow on any number (20+ at last count) of
operating systems with the same command set. This saves me from the mental
overhead of having to pick up Mac-isms, which is nice.

Also, binary installs!

------
akubera
I've been using macports for years and am excited by the prospects a "social"
coding experience will bring with a much lower barrier to entry for
contributions.

They say they will stick with Trac for dealing with issues. I understand that
for managing the ports collection, but are they planning on keeping "base"
issues (i.e. the application code) off the github as well?

I don't know how well different repos and issue trackers interop, but it seems
like an open-source solution like gitlab would offer the (potential for)
customization/integration more readily than github.

I'm sure they just desire a turn-key solution and don't want to manage a whole
new project, but maybe, one day, they'll want to unify the experience again.

~~~
peatfreak
> a "social" coding experience

Do people still buy into this? I feel this phrase was just a marketing ploy by
GitHub.

~~~
akubera
In retrospect, "social" was the wrong word; what I really meant was "a place
people already have an account and may contribute" i.e. a large, established
community.

I'll leave the question of "is it a social coding experience?" to the experts.

------
hkjgkjy
For anyone using homebrew or other package manager, and who has an afternoon
free; I'd suggest checking Nix out. It's very nice to define an immutable
manifest and have your system derived from it. If you love pure functions,
you'll love Nix.

~~~
stock_toaster
I hear pkgsrc[1] is pretty decent for osx as well. I keep wanting to try it
out, but haven't yet.

[1]: [https://pkgsrc.joyent.com/install-on-
osx/](https://pkgsrc.joyent.com/install-on-osx/)

~~~
aorth
I've been trying to like pkgsrc on Mac OS X for a few years now. The one you
link to provides binaries, and is sponsored by Joyent. The main deal breaker
for me there is that they only update their packages every quarter (currently
2016Q2), so you have to wait if you want bug fixes, security updates, etc.

I just had a look again and found that ffmpeg is one minor version behind
behind stable, its binary is annoyingly called "ffmpeg3", and it was compiled
somewhere with LLVM 6 / clang 600, versus LLVM 8 / clang 800 on my macOS 10.12
system. I tried to compile it manually (after a shallow clone of their
massive, 250,000+ commit git repo), but failed.

For me Homebrew does the right thing here — they basically turn my Mac into a
rolling release Linux desktop like Arch Linux, which is great for the userland
type packages I use: openssh, zsh, tmux, postgresql, ffmpeg, git, vim, rsync,
etc.

~~~
jperkin
I switched from building from quarterly branches to trunk a while ago, so
those packages are actually updated with the very latest every few days.

------
newsat13
I never get the logic of how whole heartedly opensource projects embrace a
completely closed source software. I get it that not everything can be open
source but there are already good open source alternatives for hosting.

~~~
Steltek
Honestly, I had the same thought years ago when many long time Linux users
moved to OSX. But then, we're speaking about the same userbase here.

------
stadeschuldt
I hope this helps with the adoption of newer versions of packages. I have used
MacPorts in the past (and Fink before) but I am supper happy with Homebrew
these days. What I disliked about Macports was:

1\. Ports define which compiler to use. Sometimes I had to install a small
tool and first it would another version of gcc. 2\. Ports were outdated a lot.
I developed a project using the Grails-framework and it was a couple of
versions behind the current stable release. Just checked: Grails port is at
version 2.2
[https://trac.macports.org/browser/trunk/dports/devel/grails/...](https://trac.macports.org/browser/trunk/dports/devel/grails/Portfile)
while the current version being 3.1.10

With Homebrew the adoption rate seems much higher. Also you don't depend on a
single maintainer.

~~~
vorg
Probably doesn't matter because not many Grails 2.x projects are being
upgraded to 3.x in the wild anyway.

------
ktta
Wait, why does [https://www.macosforge.org/](https://www.macosforge.org/) have
a cert that says Apple, Inc. Is Macports funded and managed by Apple?

~~~
amake
MacPorts isn't; Mac OS Forge is. From your own link:

    
    
      Copyright © 2011 Apple Inc. All rights reserved
    

MacPorts is hosted on Mac OS Forge, but it is not run by Apple; it merely uses
Apple-provided infrastructure.

~~~
ktta
Got it, thanks!

------
cm3
This seems to have coincided with a practical cause to look for a new place:

    
    
        But now that we have to leave Mac OS Forge anyway, it makes sense
        to convert to git and take the opportunity to do some much needed
        and overdue restructuring[...]

------
CraftThatBlock
This is long overdue. Google slowly been doing the same with moving from
Google Code (which was supposed to be dead? It is though?) to GitHub, but a
little progression is better than no progression.

~~~
LukeShu
Google Code the public service is dead. They still have internal, but publicly
visible, hosting for things like Android and Chromium; which they seem to be
rebranding as Google Source, or at least using the googlesource.com domain.

------
yepperino
It's probably been stated a million times before but it's hard to remember
what coding was like before github. CVS and subversion - what's that? Github
is so pervasive that when a project uses another git code sharing site you
just get annoyed. Github Issues may suck, but it's so darn convenient and so
well integrated. It's far worse when a project uses another ticket tracking
system and just uses github for pull requests. Just give in to our new code
overlords and go with the flow.

~~~
peatfreak
> Just give in to our new code overlords and go with the flow.

No. They are turning coding into a monopolistic monoculture. Not everybody
loves pull request-based workflows, you know.

~~~
yepperino
You're right. I'm going to go back to uuencoding my tar files and posting them
on usenet.

~~~
mwfunk
You clearly are far too young to have ever done this. :)

------
RubyMyDear
Or you can run the Windows Subsystem for Linux and have real apt-get or yum!

~~~
aphextron
I'm with you on that. This effectively ended any reason I still had left to
develop on OSX.

------
halis
Good for you guys! Lol wtf is Forge?

