The title makes it sound like the number of employees at Github scaled to 25k. The actual meaning though is that the number of Github contributers / participants at Microsoft increased to 25k.
Quote:
"At Microsoft today we have almost 25,000 engineers participating in our official GitHub organizations for open source, a great number of them contributing to open source communities throughout GitHub."
Maybe it just sounds that way to engineers then; I'm an engineer, and I read it the same way GP did. "on" is the preposition I'd use if I were describing the engineers as working on Github (as I just did right now)
I'm on Github and I'm also on Facebook, but I don't work for either of them, and I don't think either of those statements is in any way confusing. I think the confusion is due to the use of the term scaling. Github has 37 million users, so 'scaling' it by another 25k is kind of meaningless.
Having said that we know Microsoft owns Github. If the same article had come out in relation to Apple we'd immediately know what it was talking about without any confusion.
Sorry for any confusion! I originally intended this as an update to a previous post (years before we acquired GitHub) that had the title "From 20 to 2,000 engineers on GitHub: Azure, GitHub and our Open Source Portal", so was attempting to go for a good side-by-side comparison.
Yes for a native speaker its obvious unfortunately not every one is and gets caught out.
When your writing potentially for non native speakers you have to be careful.
I am doing a document that may well be read by our European co workers, so I am making sure to use basic grammar and explicitly explain what a "synonym" is in case I accidently confuse them.
No, it's not clear at all. You can read it either way. Github is now a product for Microsoft. Teams work on products. The title was misleading and poorly written.
Title could have been, "Scaling Microsofts GitHub usage from 2k to 25k teams."
Or "Migrating the remaining Microsoft engineers into GitHub organisations, a scaling story from 2k to 25k contributors.
It is actually straightforward. Typically, to maintain the code, you need twice as much engineers than was needed to write the original code.
Of course, you could write half the code in the first place, and then you will be safe - your engineers can maintain all the code themselves, you don't need to hire more of them.
But this strategy has no place in modern software development, where we want to move fast and break things, since we can always maintain the code later, post-IPO, with more engineers.
> Typically, to maintain the code, you need twice as much engineers than was needed to write the original code.
As a non-coder this sounds horribly inefficient. Isn't coding also about automating tasks so people don't need to do them manually anymore?
But with the above scaling, we'd always need more humans to solve new problems generated by coding itself, which feels quite counter-productive to the original intention, that of automation so fewer people are required for the same work.
This is more about Silicon Valley start-up culture than about how coding itself works in a perfect world.
Here's an example of how extreme it gets. Imagine you work in a commercial-facing start-up that blows up seemingly overnight.
In those kinds of companies, you'll have a core product that got super popular but was built by a small team. But now the investor money is coming in and everyone is taking about "throwing more coal in the engine". The company has to keep showing growth to keep investors happy but they essentially got lucky with the original idea and have no idea how to repeat it.
In an attempt to accelerate growth, management spins up 10s of new teams to build out new lines of business. They'll hire a bunch of product managers who will come up with lots of new spin-off products that need to be built ASAP so the CEO can talk about them with investors in the next quarterly call. All of a sudden the company has an ad-tech team, a customer loyalty tech team, an affiliate marketing team, a local retail commerce team, a physical gift cards team, a "whatever mobile SDK Apple announced at the last WWDC" team, and so on. And all these teams need supporting services so you get another wave of new teams who build supporting services. And of course now no one is really working on the original product that is generating the revenue because it won't get anyone promoted since it is already "mature". Everyone has moved on to new teams where they can "make a bigger impact" aka claim responsibility for moving a metric so they get more money.
Jump forward 24 months later and almost every one of those ideas will have failed to gain any real traction in the market and definitely won't have made a profit. But now a business that used to be run on a simple monolithic web app maintained by 20 people has been replaced by a 1000 person dev team building 75 microservices to power all these new verticals. But when all the new verticals fail to grow much, all the best developers move on in search of new projects more likely to get them promoted so you end up with a second wave of 2000 fresh college replacing them that all in aggregate generate barely any additional value over just having kept the original webapp going with the original team.
Maybe you could be a bit more charitable in your interpretation? It's obviously not the meaning you chose first, so it's more likely a mistake than anything malicious.
It isn't charitable to impute a suggestion of malice to the adjective "misleading". The headline does mislead most of its readers, regardless of the motives behind writing it.
We hold headlines to a higher standard because clickbait is so awful. Even if only mistakenly so, this headline functions as clickbait.
Nice to see that MS is very serious about open source. This is a huge change from back when Steve Balmer was still in charge and open source was a dirty word.
Employing this many people to work on open source costs billions. I'm sure not all of those people are doing this full time. But still, this represents an enormous investment. That just goes to show how incredibly valuable OSS is these days. That's similar to the net worth of some open core companies that have been debated on HN recently (Mongo, Elastic, Redis, etc.).
MS is getting plenty of return on investment. For example a lot of their development tooling is getting significant external contributions. Co-developing software with externals makes economic sense when the primary function of that software is to help people find their way to your for profit services and software. This reduces their cost, makes the software more valuable, and grows the user base of the software. More users means more opportunity for these people to find their way to for profit MS stuff. Even as a recruiting tool this is super valuable since no doubt many external contributors are on the radar for hiring.
Just having a lot of developers give up their mac books and instead choosing to run windows again increases the chance that they might end up in Azure, which as we learned recently mostly runs Linux stuff these days. MS is relearning that staying on friendly terms with developers is important for them. This is something that e.g. Google or Apple may want to consider. They do lots of OSS as well of course but they seem a lot more focused on internals lately and some of what they do seems a bit hostile even. Especially Google is starting to act a lot like MS used to act.
Maybe buying Gitlab would not be a bad idea for them ...
>Just having a lot of developers give up their mac books and instead choosing to run windows again increases the chance that they might end up in Azure, which as we learned recently mostly runs Linux stuff these days.
Key point in that sentence is this: "increases the chance that they might end up in Azure". That's the big strategy change that Nadella brought in. Balmer was ingrained in "Windows on every desktop" as the company's purpose - so linux/mac/anything else was a threat.
The strategy now is, in essence, "do your compute and storage with us". In that context, Windows is almost a commodity: of course MS would _like_ you to be on Windows, but it's more important that you're on Azure.
Irrespective of how you feel about Microsoft, they've always understood the importance of attracting developers. That hasn't changed. Some (though, evidently, not Balmer) recognised a shift to the *nix-based environments - e.g. LAMP and related. There's been a steady and directed effort to address that by embracing those platforms rather than rejecting them. No better examples than WSL2 or .net core. All are saying "they're all fine - because they all work on Azure".
>Employing this many people to work on open source costs billions.
The pro-OSS stance is, first and foremost, a commercial decision. As long as you run your apps on Azure, Microsoft makes money. If the community is funding development of the tools and frameworks you use, what's not to like? Double bonus in that the firm is now seen as being a community supporter instead of an enemy.
Like Amazon, Microsoft has found a way to benefit commercially from open source. Warm and cuddly community spirit is all very nice - but it doesn't pay shareholder dividends.
Which is not to denegrate the behaviour: I'm sure there are lots of people at Microsoft for whom the spirit and values of open source are closely-held beliefs. Equally there will be others who don't hold those beliefs and simply see OSS as a convenient tool to wield for commercial success.
> Maybe buying Gitlab would not be a bad idea for them ...
I really hope that doesn't happen. They already own Github. Buying Gitlab too would reduce choice with no obvious benefit to the market.
In the past months, I feel like I see a new useful feature every week. When Microsoft acquired them I was a little scared, but I've been extremely impressed with GitHub since. Microsoft is playing the long game and I think it will pay off immensely for them.
Same, but I also noticed more 500 errors (and a few strange bugs, but that happens to any software).
I guess it's expected when a product moves faster that it breaks a little more often (and since I use it a lot, I have many occasions to be there at the wrong time), so I'm not worried [yet] and am just glad we get new features.
EEE refers to formats and later standards, where an MS product would Embrace a format/standard (e.g. Lotus 1-2-3's macros or HTML) so that people who use competitor products will also be able to use their data with the MS product and then Extend it so that people will come to rely on MS-specific extensions - the Extinguish part comes passively from competitors not being able to keep up with Microsoft's changes, Microsoft doesn't actively try to extinguish something (otherwise they'd do that at the beginning) but it happens from people switching to their stuff.
Obviously for this to work it needs two elements:
1. A format or standard that multiple vendors provide and Microsoft implements
2. The other vendors being unable to keep up with any Microsoft extensions
None of the above apply to GitHub. The first part could apply to Git itself, but Microsoft has nothing to gain by doing that as the second part would be very difficult. EEE worked largely because Microsoft's competitors were companies with limited resources and programmers, but it doesn't work when any programmer and company can help keep up with them - see how they failed to apply it with HTML despite trying very hard. Also EEE really relies on network effects (the last E comes because people flock to MS products) and they already have a better network effect with GitHub's social aspect, they do not need to try and manufacture one.
Very cool, great that the portal is a Typescript Nodejs open source project itself too.
Hope that companies can adopt this, it's pretty tedious setting up open source review committees and making it simple/keeping the friction low for developers to contribute/make their projects useful to others. Its usually death by a thousand cuts getting a lot of projects open sourced at companies.
Really nice blog post to read for anyone responsible for administering technical/billing/organizational stuff in a 500+ developer organization. A lot of problems around permissions, billing etc and how they have gone about solving sounds quite relatable and its good to know even Microsoft with all their horsepower to automate stuff in IT faces the same problems and end up with similar solutions that a much smaller company does.
That level of growth is really intense. I have noticed github getting quite a lot better recently with things like go to definition support when clicking class/function names in the projects readme or code.
I wonder how well gitlab will be able to keep up with this growth given they have about 600 employees in total. Maybe they are working more efficiently because GitHub certainly isn't 40x better.
From my understanding, this isn't saying there are 25k employees working directly for/on github. This is saying they have a lot of distinctly separate open source projects (e.g. VSCode) that teams work on that are hosted on Github.
A quick google suggests there's some odd ~900 employees of Github, which is the same order of magnitude as Gitlab.
I interpreted the article as 25k Microsoft engineers working on open source projects affiliated with GitHub/Microsoft (e.g. Typescript) rather than GitHub the product. Moreover of those 25k they're not all full-time continuous or even contributing on company time.
With more resources from Microsoft I am hoping Github would help and push Ruby Rails forward. There are relatively few people working Rails / Ruby Core working in Github
Quote: "At Microsoft today we have almost 25,000 engineers participating in our official GitHub organizations for open source, a great number of them contributing to open source communities throughout GitHub."
Quite misleading IMO.