It won the first prise of under 22 programming contest in Japan on Oct 21st, 2019, created from 2019 August in several weeks alone. Naoto Uehara, the developer was a Python user who started to use C++ and did not like C++ so he created Python like language to replace C++ by himself.
>Those limited examples didn't seem to be the spirit of Joel Handwell's wish.
My wish is the same wish as the open letter dear-github (https://github.com/dear-github/dear-github) signers and not to host open source github in other server than github.com. Just hoping to see requested feature implemented earlier by cooperating with OSS community. I wish to still use github.com after it's open sourced. So for me, the limited partial component open source can be a starting point and the open source effort do not need to go all the way to the production backend which is distributed performance optimizing hacks usually not directly affects UX/UI.
If Github was made with micro services architecture, it could be split into open source "Client side + Test-backend" and closed sourced "Production-backend". Backend can be composed of some interface and multiple implementation such as test impl and prod impl. “the secret sauce” could be the "Production-backend" and MS have good in-house talents who operates Azure so no need for the help from OSS community to improve backend.
The last sentence of the open letter says: "Hopefully none of these are a surprise to you as we’ve told you them before. We’ve waited years now for progress on any of them. If GitHub were open source itself, we would be implementing these things ourselves as a community—we’re very good at that!"
I think that's OSS community want, including but not only I want.
This just isn't possible. No company in their right mind would take their monolith and rewrite a bunch of stuff just to please a couple randoms on the internet.
I think you're drastically underestimating the amount of code Github is powered by and how freaking long any type of refactor/rewrite would take. We're talking about years.
Oh, was Github monolith? I did not read any articles about their architecture so I assumed that Github could be composed by micro services, and in that case, splitting could go easier. I edited to "If Github was made with micro services architecture,..."
Does anyone have link to any interview or article talking about granularity of their architecture?
Reading Github Engineering blog posts related to their architecture. https://goo.gl/amkJfV As far as I read so far, Github looks like composed of micro services, or at least split into many distributed services.
Github has been a well known Rails monolith. Absolutely they have services that power all sorts of stuff (they have a few blog posts on it) but it's just impractical to even start a discussion on splitting it up for the reasons you initially argued for.
I've been through a number of large rewrites/reworks that took monoliths much like Github (with many many many services behind it) and split them up into modular pieces and it's an insane amount of work that can take years. You simply need very good reasons (including business reasons) to do that.
Moreover, companies at these sizes just have a LOT of code all over the place. Tooling, infra, supporting services, etc... Not to mention it's just not useful to have external contributors for a business product like Github. Doing code reviews, addressing bugs that were introduced, spending time discussing things with contributors takes an incredible amount of time.
Basically if the reason you want Github open sourced (and reworked into some weird architecture you described) is so that people can contribute to fix things and add features....Github could/will just hire more devs to work on that.
Thinking about the fact that Github have Github.com (production service) and Github Enterprise (self hosted), could it be like this?
Github.com = Github Core + Production Services and Infra
Github Enterprise = Github Core + Services need for Self Hosting
Maybe it's not worthy to proceed based on assumption but if there is something like "Github Core" which is shared codebase between prod and self-hosted, open sourcing the core can be an option?
Thanks TheHydroImpulse for the insights. So Github IS monolith. It really makes sense that splitting is too much work for just open sourcing and I do not see business gain to invest money and people into it.
Then possible path might be isolating least coupled (and small) components of client side code and open source?
Not sure if they will join conversation but just now I invited @satyanadella @jeffmcaffer @natfriedman @defunkt @bkeepers into the Github issue. If you want them comment, cast vote with +1
Misunderstandings looks like happened regarding my intention. I'm totally not interested in running my own github instance in other server just like people who signed the open letter dear-github to plead Github to add +1 button in issue which took really long to be recognized as an issue to be implemented. I'm sure if it was open source, somebody implemented the feature and made a pull request.
My intention is to make github.com "Client Side Code" better by let OSS community join into the development. So open sourcing backend and architecture is not my interest and possibly not interest of MS too. I'm not sure if Github is made of micro services, but if it is, certain client side code could be open sourced first and only that could generate great contribution to improve it.
I'm heavy user of Gitlab and disappointed because it is no longer fully open source and some enterprise features would not be welcomed to be implemented by OSS community because it conflicts with Gitlab company revenue. In my ideal world, MS splits Github source into client and backend and open source "Github client + test backend" for community to test if client code works while they make pull request and keep production backend closed. Do you think MS would be interested in this?
I think the +1 button was a really nice feature and something they should've done a while ago, but it's hard to draw the line.
If everyone contributes their pet UI feature (e.g. custom theme, use XYZ monospace font), then there will be dozens of features that only 0.01% of users use, but it increases the overall complexity of the product and maintenance burden.
+1 button could work as voting system to reduce that maintenance burden too. Semi-democratic method can be introduced to merge most voted and looks good to MS.
My words were not clear, I meant and edited to "semi-democratic" way. The voting is one indicator but I also believe strong vision and strategy of leader is the key to success.
And my point was not +1 button but splitting code into open source "Client side + Test-backend" and closed sourced "Production-backend". Backend can be composed of some interface and multiple implementation such as test impl and prod impl. Actually Github could be hosted in Azure and I do not care their backend as I go github.com anyway.
Issue body:
Microsoft open sourced Xamarin after acquisition and it was good for community. Open sourcing Github source will benefit open source community. Github was not open source for its own reason and it could be same reason why Xamarin was not. Now that Github acquired by Microsoft, would this event be an opportunity to re-consider the reason?
For example, 70% of inbox.google.com web app is written in Java and transpiled into JS. And front end is written in Closure. Inbox Android app uses the core as it is while iPhone app transpile the core via J2ObjC. Google Drive Spreadsheet, Calender are also built with this combination. I think Google values GWT not because it's good front end framework, but because of its power to share the code across different platforms.
