A monopoly is not inherently bad. They often benefit users with increased efficiency and productivity. They're only bad when progress stagnates and/or prices rise.

In this case, Github is actively competing and adding features that helps all of their users. If that means that some other companies lose market share then it's just a sign that the value proposition has changed. I see no problem with this, it's how the market works.

> A monopoly is not inherently bad. They often benefit users with increased efficiency and productivity. They're only bad when progress stagnates and/or prices rise.

My argument is every single monopoly eventually becomes 'bad' and makes progress stagnate and prices rise.

Just look at Google and Amazon. Up until I'd say late-ish 00s, nearly everyone loved Google and Amazon. I remember when Google search, GMail, Maps, street view, etc. first came out. I loved them, and I felt they were so much better than the competition. Same thing with Amazon - their selection was huge, great delivery and customer service.

I still use Google and Amazon for so much, but it's usually with reluctance and distaste. Check out Google search results these days. The ENTIRE first page about half way past the fold is ads, or AMP carousels, or shit I just want to get out of my way. But I still use them because with their heft and scale no one does long tail searches as comprehensively.

I hate to point this out on HN but it does seem relevant. If you dislike Google's use of ads, why not block them?

I think you've acknowledged that Google and Amazon provide the best services of their respective classes. Can we find a way to maintain that high standard without the crud that comes with it?

I'm still not convinced someone couldn't build a better gmail.

The web app is bloated and slow. The ads. The awkward design. Privacy issues. There's a bunch of benefits someone could offer. Fastmail tried but I still think it could be better and not based in Australia where privacy has been eroded.

The barrier to entry for doing categorization, spam detection, search, autosuggestions, and even complex JS frontends is significantly lower than it's ever been. You could even offload some of the above challenges to the client with prepackaged ML models. The spam filtering stuff could even be open sourced and community run like Adblockers. Abuse could still be handled server side.

I agree that Fastmail's location is problematic, but other than that, I would argue it is a better Gmail already, features-wise.

Now that you mention it maps hasn't really improved since streetview. Search is worse. Gmail hasn't really changed much. I guess after it's launched new features are too difficult to add for google.

What? All of these products probably have a miles long changelog.

I mean, I can assume you don't care for the change, but it's there. Streetview was launched in 2007.

Did they not see Google Maps change to a globe late last year? Revolutionary! Take that Flat Earthers!

I mean, in the end it is just a map. If it works, don’t break it.

However just recently they added an AR navigation to the mobile apps.

It’s still Mercator on mobile (iOS at least). How hard is it to push this change?

Recommend taking a look at this blog post: https://www.justinobeirne.com/google-maps-moat the author has updated a couple times. The changes are subtle and are amazing for your benefit. Not seeing the change is them getting better at easing you into the new functionality, not them stagnating.

Building new stuff is always more attractive to engineers than maintaining and incrementally improving existing stuff. Google suffers from this problem somewhat worse than most companies, where its best engineers jump to new projects and the existing products languish because it's not attractive to work on.

The Apple Maps 'street view' equivalent (coming in iOS 13) has a transition animation (for moving down the street) that absolutely knocks the socks off Google's. It was surprising to see just how strikingly better it is. I don't think Google changed it in that time.

How about the AR navigation on phones?

https://arstechnica.com/gadgets/2019/08/google-maps-ar-navig...

In what real scenario do you see a monopoly not doing exactly what monopolies do? Do they have some moral code they can't break? Do they hate money? What exactly is it that would make them immune to human tendencies?

Monopolies are subject to the laws of economics.

GitHub has gained near-monopoly status because it has provided a superior user experience at a great price. If either of those value propositions start to crumble,

  git remote add ...

Exploitative monopolies almost always have help from the state: The Patent Office, Interstate Commerce Commission, Federal Reserve, FDA, etc either grant monopoly or cartel privilege to their customers. Monopolies achieved on the market cannot be sustained without continuing to satisfy customer demands.

The point I think is that as GitHub adds more and more integrations (git + issues + fork graph + CI/CI + ...) then it's not so simple to move to another service. The vertical is more convenient until you realize you're an Oracle customer all over again.

With CI, I wonder if someone could build a tool which had some sort of DSL to define your CI pipeline, and then translated that to configuration files for multiple CI providers (Travis CI, CircleCI, GitHub Actions, Jenkins, etc.) If you write all your CI pipelines in that DSL, then moving to another provider would be just telling the tool to generate output for another backend.

(One issue is that such a DSL could only provide lowest common denominator functionality... or else, suppose CI providers 1 and 2 offer feature X but 3 and 4 don't, then if you use feature X, you can switch between 1 and 2, but the tool would give an "unsupported feature" error if you tried to generate output for 3 or 4.)

Having migrated from Travis to CircleCI for most of my active projects, I’d say their models are so vastly different it’s pretty much impossible to have an AST of sort that can be translated to both except for the simplest and most well-encapsulated cases (at least not before Travis supposedly improved Docker support, by which point I was already gone).

there is, oddly perhaps, an R package of all things that does this: https://github.com/ropenscilabs/tic

I personally find it almost scarily ambitious and am a bit skeptical because of the medium-term maintenance load.

Basically everyone I talk to despises Facebook, which gets pretty much no help from the state, but they still use it because there are no real alternatives.

My argument is that technological platforms are pretty special when it comes to monopoly power because their lock in/switching costs are so high that they can last long after they've stagnated in terms of innovation.

And they just buy up all their competition.

There are tons of alternatives just none that your friends are on.

Surprised no one has taken facebook's launch strategy. Only allow it in one school. Then only ivy league colleges. Then all colleges. Then everyone. Also allow you to import in your email contacts on signup.

That strategy created press / word of mouth and kept it youthful until they were ready for the big launch.

Facebook is different. Your friends are the product, not the tech. With Github the tech is the product.

Github is an example.

It's been less than a year since the MS acquisition. Give it time.

Microsoft is an even better example of a massive company continually competing. Their dev/tech products and tools have gotten magnitudes better in recent years.

Huh? MS is the perfect example of how monopolies cause things to stagnate. It was only when new technology paradigms allowed for the growth of companies like Google and Amazon (wrt AWS) did MS turn around.

IE stagnated for years after MS killed Netscape. No company has really ever challenged Windows on desktop PCs. It was only when new platforms like the Internet and mobile computing came along that provided space for upstarts did MS start competing again.

Sure, but that's the example of monopolies facing competition when they turn bad. Sometimes that takes a new platform shift, other times its just a better product, but either way if there's new value then the monopoly breaks down.

I think if anything, the problem today is companies that could be challengers just end up selling to the very incumbent they're competing against.

In the instances you’ve described where “monopolies” haven’t dominated the market, they were not actually monopolies because they didn’t have total ownership of the market.

A company can be a tech giant and still not be classed as a monopoly. Which are the kind of examples you’re think of.

For those that lived through the Windows 9x desktop monopoly in the 90s, the Internet Explorer monopoly, etc, they will see Microsoft as a prime example of how monopolies are terrible.

In fact the few areas where you actually see Microsoft improve things are in areas where they have experience but don’t actually have a monopoly (eg IDEs).

this is where the Valve vs Epic argument gets interesting as Valve has consistently been pro-consumer, so i have no problem with them being a monopoly.

Epic appears to be firmly pro-developer, which no matter what Tim Sweeney says isn't currently translating into an improved consumer experience.

Being pro-developer in the long term might result in better consumer experience.

Being too pro-consumer on the other hand... well, that gives you mobile gaming with heavy focus on free-to-play and plenty of ads.

Be careful what you wish for :)

Valve are not a monopoly. Steam's competition is not Epic, it is piracy.

Also Origin

As a .NET developer, this just smells like trying to rope in more people to Azure DevOps and then the Azure cloud. This is Microsoft's endgame. Everything they do is to win marketshare in the cloud.

I don't think it's an evil plan by any means, though, and their competition has been nothing but good for the ecosystem. Remember, they were evil about Windows because so many people didn't have any other real choice. They don't have a monopoly over the cloud, so they can't be bullies (and management is totally different now, too, probably as a result).

However on my very first impressions, the tools they're rolling out kind of look like Azure DevOps under the hood. There's a good chance they'll leave the github brand alone though and just make it better.

Personally, I've been happy working in the MS stack. They really want to earn the love and mindshare of developers.

I also see this as a play for cloud marketshare, but if Github can nail the “simple yet good enough” UI standard for this CI service, it’ll win out hands-down over Azure, which would evolve to become the more niche product that does more for SME, enterprise and larger teams, perhaps. Win/win, especially if they’ve a migration strategy between the services. I just hope the free Azure DevOps plan (for open source) doesn’t go away now that this exists. The more cloud companies can do to lower the barrier of entry, the better. :)

"Win out" depending on what kind of work you do. Azure will still win enterprises and large companies.

Github could definitely win out for small projects and startups.

CircleCI is fine for the private repositories of work projects, but not for public libraries.

In trying to migrate a fairly popular open source library I maintain to CircleCI, from TravisCI, I bumped in the following two problems:

1. setting up a build matrix with various configurations (JVM version, compiler version, coverage on or off, etc) is a pain in the ass (possible, but a pain nonetheless), a configuration that TravisCI has nailed

2. basic functionality, like triggering a notification on Gitter via a simple HTTP hook when the build has finished, does not work

I do love CircleCI for our work project, as it doesn't need a build matrix or notifications to Gitter and thus was fairly easy to setup.

But I also love to see some competition for my public projects.

We’ve had to build a lot on. Like support for passing state across jobs in a workflow, or branching, or triggering a workflow with parameters, or triggering a workflow from a different branch, or etc. CCI went to unnecessary lengths to not support obvious use cases, or that’s how it feels. :(

I've been there and spent hours if not days shaping builds and using workarounds/hacks to fit the esoteric manner in which CI services need your builds to run (setting up the build pipeline as a series of containers but without easily accessible persistent storage between the containers seems to be the current popular model - which is the case because it's very easy for a service provider to provide and manage the compute this way but pushes all the work onto you instead to get it working).

This problem is what I'm trying to solve with https://boxci.dev for myself and hopefully others too. The idea is it'll do all the management stuff that a CI service should do, but let you run the actual builds however and wherever you like, on your own machines, using an open-source cli. Check it out, perhaps you'll find it useful. It's launching very soon!

I think you’re conflating monopoly and vertical integration. GitHub is not abusing its power as the market leader just yet. What it is doing is what Apple has been for years: make its core product and other products work better together causing users who use one to want to use all the others.

Re this specific feature — note that Bitbucket has had this for a while now, as did Gitlab. Github is playing catch-up here.

Honestly, I think it's a good thing in general. Like you've said, being able to just do things here and cut out all of that wasted time spent connecting disparate services... I mean assuming they pull this off well, it will absolutely make things better for me personally.

That all being said, I'm not sure how the long run comes into play here? It's bad if we extrapolate a long run prediction where no one else innovates or creates something in this space. But in reality, someone's going to be annoyed by it, someone's going to start up a different solution, and whether it works or not...it'll be there. Whether it's a small startup or a big enterprise challenging - if there's market gains to be had from adding this, it'll get added.

Don't get me wrong, you're on point with a lot of things in tech. Monoculture and monopolies are becoming super "in-your-face" considering just how much control the FAANG companies have in influencing tech and the like. However, I do find it odd that a single feature release by a larger company results, more often in not, in much of HN community losing their minds over prospective world domination. (not you op, but just in general...granted similar outrage happens to small open source stuff just as much so maybe this point is moot).

As John Maynard Keynes put it, "In the long run we are all dead." But in the short run, this just seems like a super useful feature added to a super useful product that will just make things easier for all developers.

This is interesting to people viewing the events in isolation.

These happen routinely on a daily basis. And being in a strategically foundational position makes such moves straightforward.

In the developer tooling market, GitHub is foundational, obviously. So it naturally will expand, and can also easily do so.

And it was these moments I lament Google's inability to buy GitHub. All these stuff are just repeating Google has had for a decade, they would have been the perfect marriage but Google refuses to pay big money...

I think its seriously such a hard problem to solve in tech. Its so easy and beneficial even for customers if one company does everything. Github can (and does!) offer the most open, accessible, and integrated APIs possible for CI/CD to plug into. But, when Github builds it, its just another tab in your PR, which is much more convenient.

We use Jira for ticketing and Github for code storage, like many companies. We've had SOC2 auditors tell us that they'd prefer to see us on Bitbucket just because the integration with Jira is more seamless; it guarantees a much deeper audit trail to go from RFC in Confluence -> Ticket in Jira -> Code in Bitbucket -> Deploy in whateverthefuck atlassian does for CI/CD. They didn't dock us, certainly.

But they're not wrong! I agree with them entirely! There's a part of me that hates that monopolization of our stack into one company, but there's another part of me that's like "that auditability and integration is so nice, and we literally will never see it if we're using ten different SaaS providers for each thing". How do you rectify those competing viewpoints? I don't know if you can.

CircleCI invented many of their own problems. No API to trigger workflow runs and the only trigger “API” is pushing to a git branch. A horrible job-centric UI when all you really care about are workflows. Workflows that don’t let you express conditionality and assume all errors are fatal. A broken data model that confuses the same workflow on different branches with different workflows (no good way to figure out how long your PR workflow takes on average because each PR is it’s own workflow, for some reason). No good state management or data passing options. Hopefully they will sort those things out, but it feels like they went out of their way to build a thing with a crazy data model and triggers that are tightly coupled to github.

I would say that monocultures, monopolies, vertical integration, etc. are all really good at making a local maxima, but at the expense of making it harder to find things that might be better still. And... sincerely, they are good for local maxima. They have the mindshare, they have the money, they have everything they need to succeed, today. And then tomorrow will come and they'll be stuck. But that doesn't mean that they can't be good, just that costs have to be weighed.

Are there "bridges" (apart from Git itself) between GitHub, Gitlab, etc? Such could help to mitigate a vendor lock-in.

Yes. Gitlab can run CI from an external repo, and continuously replicate from another repo. And one time import all code and issues from GitHub.

(Caveat: import is broken. Worked for a few tiny repos, silently failed for our most important one, failing to import issues. Gitlab support just say "watch the open source issue tracker" , which is not really acceptable but at least more open than GitHub)