Tag Archives: opensource

Project versus Product

With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.

Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.

Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.

But even if there is a company that backs the project, one that does have engineering, QA and support staff, is it reasonable to expect an immediate fix to a vulnerability?

Whether a company backs it or not, using open source software is more like being part of a community than being a customer. I came across this phrase about free software a few years ago: “If it breaks, then you get to keep both pieces.” It’s very apt here.

My small part in trying to fix this perception is by calling free software projects and commercially supported versions products or services.

The idea here is that the word “project” implies some degree of a work in progress, one that requires effort from all stakeholders.

In my Day Job1, I often see companies expecting to get commercial quality support for free because the software is free. By “commercial quality” I don’t mean “good.” The level of knowledge and support provided by most free projects is phenomenal. Instead, I mean that there are service-level agreements and guarantees of service within a particular time frame.

As it says in “Cloud Without Compromise”:

But there is something to the old adage that “You get what you pay for.” (… there’s a world of difference between building systems for pet projects versus designing for the needs of enterprise.)

Those service level agreements come with a cost. If you want a fix or an enhancement, you’re welcome to ask a project for it, but it might never come or, if it does, maybe not on a timescale that helps you. The rules change when you pay for the help.

My hope is that those companies that only ever take from open source projects and never contribute learned a lesson. By helping keep the project healthy, you don’t even need to be altruistic. Think of it as insurance.

If you use the software, there are many ways you can “pay it forward”: share enhancements and fixes, write documentation, share your knowledge and experience to bring in more users, or help other users with community support. But if there’s a mechanism to pay for it, the simplest way for most users is cold, hard cash.


  1. An open source database, so I have both skin in the game and bias. However, I think I’d be saying the same thing even if I worked for a vendor of closed source software. ↩︎

Is git too hard

I stumbled across “On git and cognitive load” and it got me thinking. That post led me to “Oh shit, git!?!” and that got me thinking further.

But first, a disclaimer: this is a post more about having perspective than providing answers. If I knew a better way, I’d be doing it.

The first blog argues that git is difficult to use. Further, that it was designed with the limitations of the time and that those limitations are no longer valid constraints. A decentralised system was required when poor network connections were the norm. Now we have cloud providers and ridiculous amounts of bandwidth.

The second post notes that people keep getting themselves into a bind, with some helpful tips on extricating yourself from those situations.

The fun thing to note here is the kinds of problems that we need to solve with git:

  • I missed a file from a commit
  • I put the wrong commit message
  • I put committed a change on the wrong branch
  • I need to remove a commit

To me, the fascinating thing about all of these things is that in the systems that came before git, it wasn’t possible to do any of them. Once you made a commit in Subversion, that was it. It was in the repository and immutable1.

Missed a file from a commit? Shrug

Committed something you shouldn’t have? Tough2

Also, in the late 2000s, when git was just starting to take off, an argument against switching was that the commit history was not sacrosanct; the record could be changed. Subversion’s behaviour was a feature not a bug.

In the next decade, we’ve changed mindset so much that the ability to change a commit is now expected, even when we know that it can cause problems.

Similarly, while git’s distributed nature certainly adds to its complexity, it’s both fantastically useful and not a source of its worst behaviours. I can sit on a plane with no internet access and still have most features. I can move my repo between cloud providers or host my own. When my broadband or AWS goes down, I can continue working.

Maybe rather than move to a proprietary, cloud-based source control system — which is what the author of the first piece is really advocating — we should remember what we gained when we moved last time.

Git is tricky. But rather than return to a centralised system maybe we should fix git’s user interface. Being able to fix past commits is useful, though we we should be able to do so without messing up our code or, especially, the code repository.


  1. As ever, it was always possible to hack the repo but in my experience this was frowned upon. ↩︎
  2. I do remember a time when someone committed a password. It took a lot of time and expertise to scrub it from the history. ↩︎

Giving Back

A few years ago I was very much “into” the whole open source movement. I read LWN (still do, actually). I bought a copy of The Cathedral and the Bazaar.

But one thing I never really did was contribute to open source projects. I never really had much need. They largely did what I wanted and when they didn’t, well, the modifications were too big to consider attempting in my spare time.

And now I have a couple of applications in Apple’s App Store. I get the impression that a lot of apps you see there these days are mainly collections of open source code bundled together with some glue code and some new graphics. I know it sounds bad when you phrase it like that, but I don’t mean it that way. When you’re coding to a deadline and to cost this is a perfectly valid way of doing things.

But neither Yummy nor www.cut are like that. They are almost entirely my own code. Why? Two main reasons.

The first is historical: Yummy was initially developed when the now infamous NDA was in place. Developers couldn’t share code even if they wanted to.

Secondly, I like to minimise external dependencies. The iOS platform changes fast enough as it is without having to wait for other developers to update code as well. Of course, open source means that I could fix it myself but that probably means looking at code I’m not completely familiar with and that takes time. The desire to remove third party code led me to remove AdMob in Yummy Browser and www.cut and replace with Apple’s iAd, even knowing that the fill rate was very low ((Early indications are that, even with the lower fill rate, income is not vastly different, and this is with only two countries active at the moment with iAds.)).

Ultimately, however, there’s too much great code out there to avoid it altogether. The current, shipping version of Yummy has two open source components and I have just released a (tiny) third one.

First is the Facebook Connect SDK. I have not made any modifications to this.

Second is InAppSettingsKit. This some software that duplicates the Settings screen and allows them to be included within the app as well as in the Settings.app. I made some minor fixes so that it works on the iPad (independently fixed and pushed upstream) and I added a “Log in to Facebook” cell. I’m not sure how common a requirement this is likely to be, so I’ve not pushed it back to the maintainers but I have made it available in a separate branch:

InAppSettingsKit

Third is something that should really be included in iOS itself. Apple’s guidelines say that when your app is sent into the background it should close any menus that are open. In “iPhone Speak” these are called UIAlertView (dialog in the middle of the screen) and UIActionSheet (menu from the bottom of the screen).

In addition, the iPad had a further requirement: there should be only one menu open at any given time.

I created UIViewAutoDismiss to help:

UIViewAutoDismiss

This code is inspired by a question and answer on Stackoverflow.

My delicious.com bookmarks for December 22nd through December 27th

My delicious.com bookmarks for February 7th through February 9th