8.5 KiB
Who is in Control
This week I worked a lot more than usual. So much I didnt take the time to take a look at HN. So during my morning in the week-end, I started to read what I missed. And here are a few articles I read along their comments:
Such article have existed for years on different products. What is their common point? Software tooling and their potential change and disparition.
Accross the years, to many times I saw tools I used disapearing from my environment. By tool it could be: applications, web applications, web sites, I think we can also include programming languages, control versionning tools, building tools, package manager, etc…
The story can be quite different. Sometimes the disparition of a tool is positive, because I found a better one (for me at least). But too often the tool simply disapears or worse downgrade its quality. I think we can find different names for those softwares:
- bloatware: remember digg, stumbleupon, windows?
- downgradeware: Swagger-UI v3 (v2 is neat), reddit new redesign (looks better, but slow)
- payware: Useful free service ask for money now. Or cost a lot more.
- crapware: Stop to works, quality degrate unless you pay: Twitter streaming API?
- dieware: Remember Friendfeed, Google Reader™, etc…
- etc…
So regarding Github Codespace; the integration of VSCode™ inside GitHub™ I think this could be worse than a disapearing tool. This is what I would call a trapware.
trapware: A software that is intented to put you inside a closed ecosystem. By slowly but surely add features that while looking great for the user at first sight will ensure to entrave other tools to interoperate.
Furthermore, the fact that Microsoft is involved has a taste of Embrace, Extend and Extinguish.
I think the real concern is that it could become a work framework. So if sufficiently businesses start to use this. This could impose the full tooling on a lot of developers without giving them the freedom of choice.
For a startup CTO/CEO this GitHub™ Codespace™ could offer the following advantages:
- security: impossible or very hard to steal the source code by a single dev.
- homogeneity: all dev must use the same development environment. Thus the integration of new dev is faster.
- cheaper: don't need to pay for a full featured, fast machine to each new developer. A less performant machine able to display an electron app will do the trick.
- stats: you can observe the throughput of your developers. How many commits a day, how many lines of code, etc… How much bugs involved which part of the code and thus which dev to blame? How much time the dev is typing, moving its mouse, how much copy/paste is involved, etc…
For the single developers and open source developers this offer:
- homogeneity: if I learn how to work in this environment, I'll be easier to recruit and I'll know how to work fast.
- lower barrier to entry: for an opensource repository, it will become much easier for anyone to propose a PR to fix some issue. No need to local clone the project, no need to download all the dependencies to test it locally, etc…
But the price to pay is hidden.
- First, you are now, not able to choose your local working environment on your machine.
- GitHub™ can still change so much to become one of the previously
mentionned
/.*ware/you don't want to be involved with. They could forces you to pay a lot more, remove features, redesign to a bloatware, make it harder to interop with other platforms (prefer Azure to AWS etc…). - If everything involve machines in the cloud via the browser and via authorized plugins only. A lot of tools, features will never be allowed in this new ecosystem.
- Surveillance on meaningless or wrong metrics about your work. Instead of being evaluated on the feature you shipped or on other higher level metrics. It will be very tempting for your bosses to find flaws in your working habits. We are already living in a world were surveillance, metrics and stats are too easy to grab about a person. And anyone involved know this is all bullshit. Human are very good to play those kind of games. So people really working hard for the best will certainly perform badly compared to other people that simply trick the system.
So if the endgoal of GitHub™ is really to help open source and single developer. And more generally provide simply a better working experience by adding a new tool without any hidden marketing plan. Yes great. But I really doubt a company like Microsoft™ offer anything without a plan to make it worth it.
Until here I mostly talked about the Github Codespace article and HN thread reaction. Where I saw a lot too much enthusiasm about this news for my taste.
The Zoom acquires keybase is just another story of a dying product. Apparently the keybase team will probably stop maintaining keybase. The idea behind keybase was pretty nice. And they filled a gap in the current open source world.
The last article I mentionned was Making Emacs popular again. The first comment in HN was about how VSCode is easy to start with as compared to Emacs that need a lot more time to configure correctly for your needs. Yes, VSCode certainly just work and is easy to use. But Emacs is another beast. VSCode can become bad very fast, you don't control how it will evolve. The fact that this is a succesful Microsoft product does not garanty it will keep its currently quality. Emacs on the other hand is 44 year old and was designed so that it adapts to you. You are the one using libs and customizing it.
The argument to chose VSCode instead of Emacs look similar to me to the debate "Frameworks vs Libraries". Frameworks are easier to start with, but soon you find corner cases were you start to fight against them.
A Library on the other hand, is just a bunch of helpers you can use. And if you need another functionality, just make it using the libraries. But you have a lot more work to do yourself.
The common pattern I see during choice decision is often reducible to:
- Easy now, but less extensible and more difficult later
- Harder now but more extensible and less potential blocker in the future.
And mostly the answer is not hard to infer. If you are going to use a tool a lot, the difficulty to start learning it is not that important. If in the end the tool help you to go farther.
So if you're going to make a living with it. And use this tool a lot I highly suggest the second option.
I consider Emacs to be of the 2nd option when compared to VSCode. Harder to start, but with a lot more control and potential power that you will probably never be able to get with most modern IDE/Editor. Also choosing a Free Software1 gives you a lot more control about its future.
A few last words about Emacs, because for now I can state that this is an amazing tool which when used correctly will improve your coding experience and project management a lot.
If you want to start using it from something like VSCode I suggest you to start by using either spacemacs or doom-emacs. It will take a few weeks to absorb vim keybindings. Slowly you'll start to learn how to configure it for your needs. And I really suggest you to take a look at org-mode. Mastering it could change your carrier. org-mode alone would be enough to use emacs. But there are a lot more to discover.
The first difficult aspect when faced with open source is the lack of centralization. Instead of having a big bundle with everything prepared to work you generally need to install each part of a big system separately.
note I said free software and not open source; c.f Why Open Source misses the point of Free Software