slgeorge
1. Startups
2. Scaling/Growth
3. Existing company expanding from USA->Europe or Europe->USA
It's not as good as Silicon Valley for any of these, but no-where is. It's also not that good if you're trying to IPO, again no-where is compared to the USA.For start-ups/high-growth you get a pretty good business environment (legal/corporate and day-to-day running a company is reasonably straightforward), employees with skills and the employment law is pretty flexible, there's plenty of finance around.
For Growth and USA companies that are expanding into Europe then London/UK is somewhat easier to understand than other European geo's. There's an aligned language and there's more cultural touchpoints - it's kind of a mid-point culturally/institutionally between Europe/USA.
For funding/driving to late-stage and IPO there just isn't anywhere like the USA. But everyone has to expand to North America eventually, so it can be fixed at that point. Also, PE funding has changed a lot in the last 10 years, so if you're not on the 1-in-1000 rocketships there's a more steady 'good' path which is totally viable.
The other one that's confusing is that "tabling" something means the complete opposite.
I would separate 'politeness' and 'indirectness' a bit. I generally agree about 'politeness', there are plenty social forms that Brits still follow. For example I found the language/manner of New York attorneys pretty 'aggressive' the first few times.
Indirectness, is definitely a thing - Brits speak to each other or signal disagreement in ways that's clear to another Brit, but maybe not others. The use of silence, but also some words that depending on tone can mean different things which I think is difficult for North American's to interpret.
> I couldn't even hope to get employment in tech in the UK or Europe without a degree
Maybe this is how it looks from the outside, but it's not how it works in reality.
My evidence is I've been working in 'tech' for 25 years and having hired people across the UK, Europe and North America. Tech is one of the most accessible career paths, particularly for areas that are novel and expanding rapidly - consequently direct experience of an area is the important currency.
Often roles will advertise a 'degree' or equivalent industry experience. The only roles I can think of where this could be an issue is trying to join a large corporate organisation in their 'graduate' programme (e.g. a major bank), but that's the same situation in the USA as well.
As the projects never done this before it should be super interesting. So submitted this for anyone that's a current user, or tried it in the past.
For those that don't know Guix is like Nix, but uses a single language (Guile Scheme) to define and configure the system. It's has four elements:
- a package manager that can runs on top of any Linux distribution (e.g. like homebrew)
- a dotfiles and home environment manager
- a complete GNU/Linux distribution
- a way to create isolated development environments
I don't mind people rewriting things in <insert-name-of-tech-I-like> but "modern" as a value seems pretty loose, and it's often at least arguable whether it's objectively better!
For 'servers' the nice part is being able to prepare a declarative operating system configuration and play with it locally (VM), then it can be deployed to the remote node and you know it's going to be the same. If something goes wrong it's easily to declaratively roll-back. Here's a nice starter post (https://stumbles.id.au/getting-started-with-guix-deploy.html). The deploy capability definitely needs more hoops to jump through and it's not without rough edges - but I think it's really cool. There's active ARM and RISC-V work - I don't know how rough that would be compared to the well-known ARM ports - ask on #guix if you're interested.
My opinion is that Guix/Nix move the state of the art for Linux distributions forward. So Guix<->Nix are both similar Linux distributions, and different from previous approaches (e.g. Debian, Ubuntu, Redhat etc).
Transactional package management and declarative system configuration solve a whole host of problems. Guix (and Nix?) directly integrates configuration management into the OS, rather than as some adjunct piece of tooling (Ansible, Terraform etc). We define the packages, the system, the configuration using the same DSL. Transactions and a declarative approach improve maintainability, reproduciblity and might limit the amount of time I spend messing with different tooling ;-)
Guix is more similar to Debian, with only 'Free Software' applications in the main archive.
For proprietary codecs, firmware and so forth there is the Nonguix channel. Again, this is fairly similar to how distributions like Ubuntu have handled this line in the past.
I need Chrome and also have some games loaded using 'channels' - heh heh - another post:
https://www.futurile.net/2022/12/04/proprietary-apps-on-guix...
A lot of Guix users use Flatpaks.
Guix does receive security updates, and those are added to the archive immediately. I haven't had any problems myself. It's definitely a 'community' project, so you have to enjoy doing a bit of hacking!
* Guix Shell https://www.futurile.net/2023/04/29/guix-shell-virtual-envir...
I did two specific posts about using it for 'development' environments. You can also 'fix' the environment (think a git hash) and use the declarative configuration to share it with others:
* https://www.futurile.net/2023/04/30/guix-reproducible-dev-en...
* https://www.futurile.net/2023/10/17/guix-time-travel-dev-env...
Hope they help - if you have a play and get stuck the mailing list is really good and I posted about the Meetup further up.
* a package manager on top of an existing Linux distribution (think apt or rpm)
* a development environment (think Python venv but for any language)
* a VM system (like Docker but declarative)
* a Linux distribution (similar to Nix)
It's a small and friendly community - we recently started an English-speaking online user-group:
https://www.meetup.com/guix-london/
Next meetup is Monday next week - please come along!I also did an Intro post to some of the advantages and challenges a couple of years ago:
https://www.futurile.net/2021/09/26/guix-alternative-to-snap...
One thing to bear in mind is that at Weaveworks we made massive contributions and did our best to be part of the community in the right way:
* Flux * Flagger * Cortex * Ignite * Weave Net * and a whole host more
Oh and there's a load of people without jobs tonight - wondering about their futures - hopefully people will see the talent and the contributions and find roles for them.
People across all teams: marketing, product, engineering, dev-rel, consulting / CRE, customer success and business operations
Across the States, UK/Europe and Egypt.
If you can help these fantastic people find new roles - please get in touch!
I don't see how this is 'Embrace, Extend, Extinguish'? This license guarantees that the code becomes Free Software at a maximum of 4 years - and in this case they've specified a shorter time period.
I'll give you that there are lots of games played in open source, so I understand that feeling of cynicism. But, this actually seems like an attempt to add some nuance to the commercial<-->free divide.
The reality is that many 'commercial' OSS companies have to take the open core route because understandably investors expect a return on their money. There are exceptions to this, but they are pretty rare. In fact, there are probably a whole set of SaaS companies that could be open source, but don't do so out of the fear of someone taking their code and 'free riding' them.
Finding a way to prefer the entity that sponsors/incubates the code base, while also genuinely allowing a community of contribution around it (not free riding) would be very beneficial in lots of situations. Maybe a better critique would be that this has some similarities to the Trolltech QT approach - but that's a different argument.
When the distros started to expand, being a smarthost was the most common configuration. Today, I agree with you the only reason for any sort of SMTP daemon is for programs to send email - all the users are on Google/Slack.
Similar to your comment the ability to see exactly what is installed, with repeatability is fantastic. For my personal use-case the ability to install an application in parallel to Ubuntu's is really useful.
I'm often amazed by the intrinsic motivation and long track records of people working on open source.
a. Build something that solves your personal problem - later find out if that applies to others, and whether they are willing to exchange money in return for a solution. b. Find out what problem others have (ask them if they'd pay for a solution) - then build something that solves it responding to their feedback (if it does, ask for the money they said they'd give for a solution).
Maybe another way of looking at it is that (a) is about saying what "your vision is", and (b) is about finding out what "someone else's vision is".
Following (b) is a better commercial/sales strategy, but you're right that it might involve building something that you don't care about - because it's not for you, it's for the customers - which is probably why it's work and we do it for monetary compensation rather than just joy.
Perhaps the most difficult outcome is that many Founders now read product books or go to accelerators where they're told to follow strategy (b). They then basically do (a), while pretending they're doing (b) - but really all they do is listen to people who are positive about their vision and ignore any counter evidence.
Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.
Vim favours being available on multiple platforms, alignment with Unix tradition and stability:
> Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)
Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.
The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.
I love many of the NeoVim's new features and capabilities.
But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.
As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.
... most people aren't arbitrary, they have different experiences or perspectives which leads them to 'rational' decisions.
It's equally hard to do good or bad management, since most of the time you have no idea if you're achieving either outcome - and neither does anyone else.
The problem with all forms of management is that it's completely unscientific. The main resource you're working with is a "human" which has emotions and who will respond to inputs in very different ways depending on all sorts of factors you as a manager don't know about.
And, when you put a group of "humans" together you might expect a direct increase in productivity - 6 humans should be 6x more productive right - you'd be wrong. Also, for whatever reasons the dynamics of the individual humans change in groups! They are differently productive depending on what other humans they work with! And, since there's no scientifically proven way of categorising them - you can't even tell which ones will work well with other ones.
Oh and the big joke, even if you get that working, sometimes they *change* and then some part of the group is broken for some unknown reason.
Then there's the problem of measurement, and I don't mean the team members. As a manager trying to measure the outcome of your own efforts is difficult, bordering on impossible - maybe something you did changed something, on the other hand it might be some other factor you know nothing about.
Finally, you might expect that the individual "humans" might know what makes them individually more productive. But, nope - most humans have no idea what makes them individually more productive, and then throw in a team setting and you're in a whole world of pain. Some of them think they're "analytical" and can't tell that they're dragged around by their emotions, love life, caffeine, commute or sunshine quota. There's a variety of 'received wisdom' stories they tell themselves, but it's often just a random walk.
So actually ALL management is hard, and you often have a equal chance of doing it "well" or "badly" on pretty much a daily basis. It's as hard to do it badly, as it is to do it well since most of time you're not sure if either is happening.
I suspect a lot of the dynamics of my choice are because I wasn't coming from any sort of Lisp background previously. If you were coming from Common Lisp then things would feel different.
I've been focusing on ClojureScript (https://clojurescript.org/) as you get the benefit of interoperating with the Javascript ecosystem. The fact that there's a strong community around both Javascript hosted and Java hosted gives a wealth of library options.
Overall, the tooling has been getting a lot closer to the sort of experience that contemporary developers expect. The Calva plugins integration with Visual Studio (https://calva.io/) makes it easy to get started - you can even run it online with gitpod (https://github.com/PEZ/rich4clojure).
That just leaves learning the language - the slight changes in syntax (brackets for different data types) definitely help early on, and for the most part Clojure discourages people going down the path of macros which means reading other peoples code is reasonably accessible. The main struggle is that it's a language used by a lot of advanced or full-time developers, so documentation is pretty dense and it can take a real commitment to understand the detail.
It may not be 'correct' enough if you're coming from other Lisps, but coming the other way from C/Python etc I've found it an accessible and practical option.
For ClojureScript I guess there's lots of options since you can access the Javascript ecosystem.
One of the benefits of being hosted is that we can always fall back on the host language's options.
Sorry, that's not correct. It goes against your opinion of what open source should stands for, and many projects run in a way where everyone can contribute. But, it's not the only way.
The license determines how the code comes, that's the only rule. There's no rules about how a community must run. It's for the code creator (maintainer) to determine how or even IF they want a community of contributors. There's lots of ways of doing open source!
And saying it's not "open source' if you don't do X outside the license is just a No true Scotsman.
In fairness, in the article he does say why all these communications tools are a problem in his opinion.