Free software hijacked Philip Hazel's life
lwn.net
lwn.net
I took over some fairly widely used Go projects, but only after they were archived. I had no idea they were looking for someone to maintain it.
There's a bit of a catch-22 here:
- If a project is already well-maintained then no one really needs to contribute anything.
- If a project is poorly maintained due to lack of interest or time, then this will also discourage contributions – the first think I check before contributing is whether previous PRs are actually getting merged.
For larger projects where there's always something to do, like Exim, this usually isn't a big issue. But for smaller more narrowly scoped projects like PCRE2 this is more of an issue. I'm not surprised he's having a harder time with PCRE2.
This LWN article is helping to spread the word.
(I worked with Philip before he retired.)
Also, about 90% of the people respond will fall through. I'm sure people say "yes" with the best of intentions, but saying "yes" in a wave of enthusiasm is easy, and then spending a lot of hours on it ... not so much.
My favourite example is someone who said "yes, I'll help maintain", was added to the GitHub repo, made a new issue with a long plan on how to deal with the many open issues, and ... was never seen again. Never actually dealt with any of the open issues. I'm sure this was done with the best of intentions (and their profile said they're a student, so I don't want to judge harshly), but this was a rather marked example that made me laugh.
It's a tired meme but we really do need some concept of "finished" in our field, along with the necessary incentive structures to enable people to do the needed maintenance on finished software in perpetuity.
it's no coincidence that corporations that own proprietary code don't have this problem.
has anybody considered that maybe Richard Stallman was wrong?
maybe it ISN'T a good idea to volunteer your time to write libraries that corporations will use to make billions, while begging for donations.
maybe, sometimes, libre licensing is a mistake specifically because it leaves maintainers with no reasonable avenue for compensation
> it's no coincidence that corporations that own proprietary code don't have this problem.
I would argue they have a similar but worse problem. Someone at google creates an awesome product. They get promoted and leave the project. Someone else is assigned to maintain the product, which slowly gets worse over time either a) because the new maintainers are less skilled/driven or b) because programmers perceive themselves as being paid to write code, and it's fun, so they're going to change things even if nothing needs to be changed.
I've seen so much commercial software get worse over time. I'm not sure if I have the causes right, but there's definitely something wrong with the model. In contrast, I've found open source software to be far better for far longer. It might stop being maintained, but it almost never gets worse in my experience.
There is no objective "right" or "wrong" when it comes to libre.
I have written dozens of libre projects. I don't want them to be proprietary. I don't want to make money from them. If I did, I'd simply use a proprietary licence, no one forced me to go libre.
Proprietary programs have a different, interesting problem: They eventually disappear. In 1995, the year PCRE2 was born, I was doing classic MacOS GUI programming on a 680x0 machine, running Metrowerks CodeWarrior as my IDE, and relying on a bunch of tools that are now gone. The proprietary technology I used in those days is now almost universally extinct. I think only BBEdit still exists.
A couple of years later, I switched to Emacs and Linux, and they're still going strong a quarter century later. I hope to get another couple of decades out of VS Code (or a fork). I can deploy Linux apps to containers. And PCRE2 is still going strong. Oh, and I can still typeset math with LaTeX.
I think there is real value in software that is "done", with stable APIs and very conservative maintenance, which can remain in use for decades. That's a world I want to live in. Let me keep using proven technology where appropriate, and switch only when I find a good reason to switch.
> maybe it ISN'T a good idea to volunteer your time to write libraries that corporations will use to make billions, while begging for donations.
I sometimes avoid letting my projects get too successful in order to minimize my support costs. But in general, if you want to earn money from software (open source or proprietary!), you're going to need to build an actual business. Using a proprietary license isn't magic. I can use a restrictive license, find no customers, and still earn no money. It's the easiest thing in the world.
If you want money for an open source project, you're still going to need to focus hard on the business part. The easiest way to do this is consulting. Your users will still capture 99.9% of the value from your software, but a successful open source project can still be turned into decent revenue—if you keep working at the business side, too.
Mostly, when I release open source, it's because I've created something useful, but I know that it would make a lousy startup for one reason or another. My employer is happy to go along. They see that a tool is useful internally, that we couldn't sell it to our customers without a massive pivot into a difficult market, and the tool isn't hugely useful to our direct competitors. So why not share it? Sometimes we get a useful PR! Even better, designing a tool to make sense as open source sometimes makes it more reusable internally.
True, but I was using Windows in '95, and it still exists. I even use the odd bit of software from that era (typically small command line things.) And I'm still using Word and Excel.
So I'm not sure your comparison holds water. In the sense that some companies keep developing a product forever, and some have a history of ending things all the time.
That's of course equally true for Free Software projects. Most have been abandoned. Most have been replaced over time.
Your point about business is spot on. If you want to make software your business then you will spend most of your time on the business part not the software part.
Consulting is one path to income. Unfortunately consulting on proprietary software pays better than consulting on Free Software [1]. Equally consulting on some large (free) product pays better than consulting on your own product [2]. Which of course is all fine. There is no reason your income anc passion have to be related.
[1] obviously I'm talking generally. But for example SAP pays better than PostgreSQL.
[2] still a generalization, but the market for say PostgreSQL consulting dwarfs the market for say MyEditor consulting.
> maybe it ISN'T a good idea to volunteer your time to write libraries that corporations will use to make billions...
If you are writing libraries that are being used by companies as part of proprietary software at all -- much less to make billions -- then you didn't pay attention to Richard Stallman.
> isn't the whole point of intellectual property law to align incentives?
Yes: which is why Richard Stallman and the Free Software Foundation specifically came up with a model which uses copyright law against proprietary software via the idea of "copyleft".
I think there are people out there who fundamentally believe in doing service for other people... as long as they aren't taken advantage of! Aligning this incentive by encoding this moral contract into a civil one is the goal of the FSF.
(Now, I won't say they nailed it... GPL2 failed to foresee and prevent DRM, and even GPL3 has issues with the new era of cloud hosting; but like, they did much better than anyone probably should have expected.)
Contrary to the title of this LWN post, PCRE2 is not "Free Software" and is actually licensed under BSD; the result is that, yes: a ton of companies use this library and they make billions.
edit: because RMS/FSF's position is not simply "all free software equally good and you should spend your time building some with any license"
For example a new feature added last month is the new pcre2_set_max_pattern_compiled_length() function, to limit the size of compiled patterns. I assume that wasn't added for the craic but in response to a real-world use case. There are also plenty of bugfixes and smaller changes.
In my comment I stated:
> a bridge needs some maintenance and upkeep, yes,
Is there a way I could have stated that to emphasize that bridges will fail if they're not maintained?
For example, I tried to implement a simple library/module system in the GNU bash shell. I was writing a lot of shell scripts and just wanted an easy built in way to load them from a standard conventional path. I didn't expect this feature to be controversial in any way. I went to their mailing lists to talk about it and it culminated in other users describing it as "schizophrenic". I now view as a huge mistake my decision to write bash scripts instead of using a proper language from the start.
I really wish more people used PEG parsing. I wrote a library for it in Haxe that was surprisingly fast despite being interpreted : https://www.youtube.com/watch?v=CtNQvjyioGQ
$ apt-cache --recurse rdepends libpcre2-8-0 | tr -d ' |' | sort | uniq | wc -l
52160> Hazel is also known for his typesetting software, in particular "Philip's Music Writer",[5][6] as well as programs to turn a simple markup into a subset of DocBook XML for use in the Exim manual, and to produce PostScript from this XML.
Even in the 90s he was a famous hacker around the Computer Lab.
(The username, for those not familiar with Cambridge Lore, indicates he was the first PH to be given an ID using the scheme applicable in the mid-eighties. Someone will no doubt reply with a more precise timeline.)
I think more and more open source projects will be targeted by intelligence services.
Open source maintainer is a stressful, thankless job which pays peanuts compared to what you could get for the skills and time.
Driven, talented individual who feels they are sacrificing for the good of society and are not being properly appreciated is the stereotype for a person who can be turned.
Turned towards... something that sounds consistent with the values for which they're sacrificing?
Or is the theory about more of an "f-word these ingrates; I might as well get paid" reaction? Or towards a role that makes them feel important or appreciated?
Would this theory distinguish people doing open source mainly because it's technically interesting to them, from those who are in it more for the community, from those who are strongly motivated by principles?
For my part, I suspect no intelligence service would really be interested in the project, and, even if they were, I'd not "turn."
Personal Integrity seems to be considered a quaint anachronism, these days, but I do run into folks, here and there, that seem to have it.
The FSB (say) dont send you a bunch of flowers and a pull request from fsb.gov.ru. We saw from the xz situation that this class of attacker can start out genuinely helpful and use sockpuppets and social engineering over a long period of time to infiltrate projects.
For all we know, (put on tinfoil hat now) there could be committers in major projects now who have spent years acting "normally" to earn trust but are sleepers.
Not so sure that I'd call it "tinfoil." Probably quite realistic.
It's easy for me to say. I write software to support a fairly small, tight-knit, demographic. We all tend to know each other, so trust (or lack, thereof) is fairly established.
The problem we have is you can’t prove the absence of something.
A person joined their Discord claiming to be a former Ubisoft 3D designer and was confirmed by other former coworkers. They began to ship actual, high quality 3D work as a contractor and earned the trust of the channel.
…and then ultimately tried to drain their wallet at the end. Best they could guess was that the scammer(s) paid freelancers and then presented the work.
Vetting people online is really hard.
This may ultimately turn out to be a real valid reason for management's "back to the office" push, even if they don't know how to express it or quantify the benefits.
Maybe a suitably talented person can assess strangers skilfully and well face-to-face, but whatever poorly-identified skills they use to do so, they can't do it via a video call or something. And this is without deepfakes and so on.
Well, it needs to be something of interest to a company that will pay someone to be a maintainer as part of their day job. Or it needs to be something that someone has built a business around--but, as you suggest, their job is now a lot more than just being a maintainer and, in many cases, they make a lot less than just taking a job at a company.
I also have to believe that if it's a true open source project (meaning, without commercial aspirations), then any stress must be self-induced. FLOSS authors don't owe anyone features, bug fixes, or explanations. And any that are delivered are totally voluntary.
For me at least, it is easy to say the, I’m quite sure, objectively correct thing. Open source hobby projects have no obligation to anybody, just release code for fun, and anybody who expects more is the problem and should be ignored.
But there are lots of reports of burnout and stress. So I think there must be strong social pressure that people fall to, despite not having any legal or ethical obligations.
I mean for most of time, all of pre-history, humans got by with informal social structures and a feeling of wanting to provide their friends continued help, despite a lack of a real state or legal framework, and mostly informal ethics. So it isn’t that surprising that people feel like they have a real obligation to users when they’ve been working on a project for a while, right? Helping others is a human instinct.
Precisely why Open Source must fund itself with things like freemium. Otherwise its impossible to justify the effort it requires in the long run. Like how the freemium format has been very successful in the WordPress ecosystem and many individual devs have made a very good living by developing their themes/plugins/services and creating sustainable communities around their software - independently without any kind of VC money. It is a good pattern that keeps the control of projects in the community's hands.
I plan to pop my clogs at the keyboard.
The coroner is gonna have to rub "YTЯƎWϘ" off my cheek.
"Hijacked" - used in the title here but not in any of the actual quotes - implies that Phillip is some sort of captive of his projects' success, but I'm not sure that's true. After all, he stepped away from Exim (an incredibly notable project) many years ago, so it's not as if he is incapable of walking away when the time is right.
So, presumably, he has only worked so long on these projects because he finds meaning and/or enjoyment from doing so. I can only hope if/when I reach the age of 80 I'll have something meaningful like this I could contribute to!
I do believe that, yes, he has enjoyed the work and "hijack" is employed tongue-in-cheek.
Are we sure this whole discussion can't be reduced to just links to xkcd strips?
This aspect isn't really specific to open source culture, it's human nature. People want free stuff. People feel entitled to free stuff. People feel entitled to the uncompensated labor of others.
Even though the histories of computers seem to focus upon computational power, it seems as though the most challenging aspect in the development of computers is inexpensive memory. I was going to say fast and inexpensive memory, then I realized that we haven't really achieved that goal.
A lot of early computers depended upon the notoriously difficult to manufacture core memory. Then there are things like drum memories, which sacrifice density in order to use stationary read/write heads. And even though these forms of memory share a lot in common with hard drives, they were actually used as the main memories on some computers.
Earlier memories are even crazier, like mercury delay lines (complex, sequential access only, and a health hazard). Even later semiconductor memories endured a long period of explosive growth before reaching useful costs and densities. (Early minis and workstations often had large boards containing only memory. Early personal computers kept costs down by shipping with single-digit kilobytes of memory.)
I wouldn't bother too much if software (and specially web pages) weren't getting bloated continuously
It's like there's a great stagnation in the amount of memory increase after each generation, but the software devs didn't get the memo
That's the ultimate "works on my machine"
I don't think it's somehow also Philip's burden to find or vet or train a successor. The code is out there. His license terms are unobjectionable.
If and when Philip stops work, let someone else who cares pick it up. Perhaps under new and different names. The links between the names Philip chose and Philip himself as the person behind the work will have been broken, anyway.
Follow-on forks won't take away from Philip's legacy one bit. They might even help raise attention that new groups or individuals worthy of gratitude have stepped up.
My dear friend Jia Tan – although I hear they go by a different name now – might be interested in taking over maintenance of PCRE.
He’s clearly aware of the problem, so there’s that at least. It is a tricky one.