Models of code ownership

As I’ve worked as a software engineer, I’ve noticed that individuals, teams and companies approach things differently with regard to code ownership. Most engineers and teams take pride in quality code, in solving real problems, and in shipping software.

The model of code ownership affects the dynamics of a team, of a company, and of the software that is created and maintained. I’m strongly in favor of collaborative ownership, with the understanding that individual engineers are stronger in some areas than others. I appreciate collaborative ownership because it engenders a culture of inclusion, participation, cross-functional learning, and openness to a diversity of ideas and experience.

On the other hand, I’ve seen it work for individual ownership of certain components of a software stack — as long as there’s a way for others to give feedback in constructive ways — i.e. the owner takes pride in his/her code, wants to learn and accept feedback so that their code can be the best that it can be.

It drives a wedge in working relationships when a code owner says “hand’s off!” or “how dare you touch my code without consulting me first!”. It also creates problems when a contributor says, “I’ll make changes when I want to, whether you like it or not!”. Such attitudes indicate a lack of trust and respect. Perhaps this is why distributed version control (with pull requests or patch submission) works well compared to the anyone-can-commit model more common with Subversion. E.g. with github or gitlab, anyone can contribute, but the code stewards get to decide whether or not to accept the request.

The same principles apply when outside team members attempt to contribute code to another team. Ideally, the recipient team documents code standards, design decisions, and if nothing else, during code review, they communicate the ideals to the team attempting to contribute the code.

Here are some articles that talk about the styles of code ownership, and the pros and cons:

XAR self contained executables via squashfs

From the world of interesting and cool approaches to solving software deployment issues:

Statically linked binaries that minimize dependency management difficulties work well for C++ executables, but languages like Python, JavaScript, and even Lua present a different challenge: How do you place source code and data (such as SSL certificates or shared libraries) inside a single executable? What do you do about the dependencies the tool might have on modules installed on the host operating system?

XARs are slightly modified squashfs files… that mount themselves when executed and unmount after an idle timeout. They could almost be thought of as a self-executing container without the virtualization. By using the squashfs format, we not only distribute data in a … compressed format…, but we also decompress on demand only the portions we need. Thanks to this architecture, XARs have nearly zero overhead in production and can be used just as native scripts or executables would be.

Ubuntu 18.04 & Gnome 3

I’ve upgraded three computers to Ubuntu 18.04. Although I appreciate the modern software (including LibreOffice), each upgrade has had different issues.

Lenovo Server: upgrade was rocky because the root partition ran out of space part way through the upgrade. I hand-recovered and managed to get it to finish. Later, the journal (systemd journal) went nuts and filled up my root partition (which is shared with /var) with log messages — causing so much I/O that it was quite slow to log in to my computer. Once I figured out how to vacuum the journal, I recovered space, and set the journal size smaller. Now it seems to be working well.

System76 Galego Ultrapro: upgraded without a hitch. However, power management is less-than stellar. It won’t go to sleep when I want it to, and it comes out of sleep when I don’t want it to.

Lenovo P50 with NVidia graphics card: It worked better at driving two external monitors with Ubuntu 16.04. It mostly works with 18.04, but it’s more temperamental. The upgrade didn’t go smoothly, aborted early, and I had to hand-recover, which, fortunately, worked out. I needed a new version of VMWare Workstation.

Things I appreciate about Gnome 3 (Ubuntu 18.04):

  • Keyboard shortcuts, including WINDOWS + left-click-window + drag
  • Window snapping: WINDOWS-LEFT, WINDOWS-RIGHT, etc. Very similar to Windows
  • High-DPI support works well, which is excellent for my Lenovo P50 with a 4K display (4K is too much resolution for a laptop screen, but it was the only option with the Xeon processors).
  • Looks great

Things I dislike about Gnome 3 (Ubuntu 18.04):

  • Clock doesn’t include day of month by default. Requires gnome-tweak tool to enable. Sloppy and difficult.
  • Too many clicks to get to network settings, including VPN. It used to be easier.
  • Can’t share my connection with wired-via-USB-cable computers anymore. Reported workaround, which doesn’t work at all for me: launch nm-connection-editor.
  • Login screen shows a background instead of a list of users, until I press a button or swipe. Please don’t follow Windows here. It’s dumb.
  • When I zoom in on a folder in Nautilus, it zooms all other folders, including my desktop icons.

Other things I dislike with Gnome — longstanding issues that existed before Gnome 3:

  • Nautilus uses too much white space between images when zooming in on icon view. It should be proportional — like windows Explorer does. I.e. when the images are 0.5×0.5 inches, it’s fine to have 0.5 inches between icons. But when the icons are 3″x3″, I don’t want or need 3″ of white space between icons! (This isn’t an issue with Gnome 3 — it’s a long-standing issue with Nautilus)
  • Nautilus doesn’t show image meta-data such as camera model for images — I like to sort by camera model.
  • Lack of a photo screensaver. I live without it, but it still frustrates me that Gnome is the only desktop, which, by default, doesn’t include one. Windows, Mac and KDE are much better in this regard.

I love using Linux, but Windows is squarely better at some things.