10 KiB
Who is in Control
This post is a reaction about a few articles I read in a short amount of time. So do not take that too seriously. But it will certainly.
I had to work a lot this week and I mostly didn't read any news. This morning, I started to read the article I missed. Here are the articles and threads I read:
I don't think I read those in that order.
A few years back, HN comments made me look at Clojure. That was also many positive HN return of experience that made me confident to use it for a serious business work. Lot of great advices regarding every aspect of the life and software programming. Project architecture, etc… Most of the time, article were good, but HN comment were really great. Of course, even after a few years, people started to explain that HN quality dropped. This can totally be an observer bias. HN quality might not have really droped but the reader has changed.
So I get it. I changed a lot accross those years. And also, yes, HN is mostly see by startupers. So this is also another big bias.
Still, I'm sad to see that the most popular opinions expressed in those discussion threads have diverged so much from my point of view.
When I see those news I see a common pattern.
One big corp kill a product that should exist for the common good. And of course, each time this is because having a common product is incredibly hard. Most "common good" products do not have what it takes to be sustainable enough. Either you create a very big open-source ness of developers that give their work freely, or you can grab enough money from different source so you can pay a few of them.
And this is why the startup model is a lot more efficient. You want a great product, buy the best best people. For that you need money and passion.
Most Free Software1 must deal with community driven development. They should often find a concenssus. They generally don't have money to pay the people working on that product. While startup looking to create popular product must take a lot of care about UX and UI. What that mean is that the product should need the least possible amount of energy and learning from the users. And this is a great thing. The problem with this approach is that most of the time it also forces users to follow the workflow and limitations imposed to make it easy to use.
And sometime worse, product simply disapears or change so much I simply didn't want to use them anymore.
So here is a non-exhaustive list of /.*ware/ that, as a user you don't
want to deal with:
- bloatware: remember digg, readitlater, stumbleupon?
- downgradeware: Swagger-UI v3 (v2 is neat), reddit new redesign (looks better, but slow)
- payware: You rely on our feature, but now, we want you to move or to pay. Fair ;)
- crapware: Nothing works as expected unless you pay: Twitter streaming API?
- dieware: Remember Friendfeed? Google Reader™?
- etc…
Regarding the integration of VSCode™ inside GitHub™ I think this is even worse. 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 really give this situation a taste of EEE.
So what is the real concern for me. I imagine a new working environment where surveillance and control on the developer is a rule.
For a startup CTO/CEO this GitHub™ full work environment offers the following advantages:
- security: impossible or very hard to steal the 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 simple 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. Like forces you to pay a lot more, remove features, start to become 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, it makes it harder to play locally with your machine.
- Sureveillance 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 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.
But the other articles and their reaction in HN show that yes, HN might not be for me anymore. Most of the top level comment in Name one idea that changed your life are about how to not fall for the trap of the confirmation bias. That's really great. But as a former scientist, this is only the very first step. I might be totally wrong. But I would have expected that the same question being answered a few years back on HN would have also provided those answers but also deeper ones.
The Zoom acquires keybase is just again a confirmation that, yes. When you chose to adopt a tool. You should ask yourself if it is worth to invest your time and energy in it. Because most of the time, the tool has a finite and short lifetime.
Finally, about Making Emacs popular again. The first comment 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. 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's a bit of the same Frameworks vs Libraries argument. Framework are easier to start with, but soon you find corner cases were you cannot use them correctly and are fighting agains the framework.
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.
So libraries, programming languages and tools have generally subject to the same debate.
- Easy now, but more difficult later VS harder now but easier in the future.
So if you are going to need a "solution" for a problem for a very small amount of time. The "Framework/3rd party tool/etc…" is certainly the best solution to choose. If you're going to make a living with it, and pass most of your time with this tool. I highly suggest the second option.
Emacs is like that. Hard to start, but with emacs come a huge power that you will probably never be able to get with any other IDE/Editor. And above this, choosing a Free Software gives you a lot more control about its evolution.
I wouldn't be surprised if in a few years VSCode started to show ads during startup ad why not in the middle of your work. On the other hand this will never occurs within Emacs unless you are doing this to yourself :).
Conclusion
Choosing a tool:
- will I use it a lot?
- do I trust that I'll use the same tool in 5 years, 10 years?
- who is in control?
- Is it worth to invest my time in it?
Most of these new tools from startup disapears after about 5 years. So if you plan on using a tool for something important for you. Take care that it will exists as it is today, or even better in a few years.
note I said free software and not open source; c.f Why Open Source misses the point of Free Software