Free software hijacked Philip Hazel's life(lwn.net)
lwn.net
Free software hijacked Philip Hazel's life
https://lwn.net/SubscriberLink/978463/608c876c1153fd31/
80 comments
I worry about new maintainers who feel the need to leave some sort of a mark on projects by adding unnecessary features and dependencies. I get it, true maintenance of a stable project, where you only fix bugs and security issues, is not glamorous.
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 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.
There are very few non-trivial projects that are truly "finished" in the sense of "will never need any changes". There's always bugs, there's always a changing ecosystem (even for C), and for many projects once in a while you do want some new features.
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.
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.
"finished" as in "totally free from bugs" is one thing, "finished" as in "feature complete and passes all known test cases, artificial and real world, known at the time" is another. As an industry we need to push the second notion as something someone can build and then set down. building a bridge instead of a steam engine locomotive. a bridge needs some maintenance and upkeep, yes, but after it's built, the team that built it moves on to another project. To contrast, a steam engine locomotor is an ongoing engineering project, which requires constant upkeep to keep the train moving. A SaaS company's backend is a steam engine. The Unix util "ls" is a bridge.
I think that's a poor example because bridges wear out and need to be maintained. There are a number of Youtubers devoted to disasters (One is "Plainly Difficult") and bridge failures are a large component of their examples.
I don't see how that undermines my point. Everything needs maintenance and upkeep. You have to re-paint the bridge and check it for cracks and do testing on it. But that's measured in days/weeks/months/years vs. a steam engine going off the rails in seconds/minutes/hours.
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?
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?
If you read my second sentence above, I think we're in almost perfect agreement. Unless I'm misunderstanding you? My definition of "finished" includes provisions for bug fixes and important features.
What is or isn't necessary is for each developer to decide. Maintainers or community being too conservative can prevent innovation from happening, causing stagnation and loss of interest.
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.
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.
isn't the whole point of intellectual property law to align incentives?
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.
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
> 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...
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.
> 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.
Permissively licensed software is still free software. The BSD licenses are approved by the FSF as free software licenses. They're simply not copyleft.
Yes but what I think previous poster meant is that you can't use a permissive license and then blame RMS when you feel used by a corporation using it to make proprietary software.
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"
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"
(FWIW, I was also trying to add a charitable shift of blame to the article title making the matter more confusing by invoking the term Free Software; but, icouturi's correction of that little quip I added--which was entirely ancillary to my overall argument, as you point out--is, in fact, correct.
It might be more accurate to say that ESR was wrong. It might be even more accurate to say that ESR regards the obvious deficiencies of the model he popularised to be features.
These are definitely questions worth considering.
> 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.
> 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.
> it's no coincidence that corporations that own proprietary code don't have this problem.
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.
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.
>> 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
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.
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.
Surely that's a decision to be made by the author(s) of the code?
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.
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.
There’s a PCRE2 issue that Philip created last week, and which I submitted here, but it didn’t get much traction. https://news.ycombinator.com/item?id=40657607
This LWN article is helping to spread the word.
(I worked with Philip before he retired.)
This LWN article is helping to spread the word.
(I worked with Philip before he retired.)
Yeah, that's exactly the kind of stuff very few people are going to see. Even this HN post here is seen by relatively few people.
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.
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.
PCRE2 is specified through its implementation, which has so many edge cases and special flags that most people can't reason about what kinds of problems it could cause.
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
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
Aren't there reimplementations of pcre2? I think that ripgrep has a pcre2 flag or something
ripgrep uses the PCRE2 library directly. Otherwise ripgrep is "pure" Rust. (To the extent that is plausible at present. e.g., ripgrep relies on libc indirectly via Rust's standard library.)
Seems like it would be a great feature on github, or for a standalone site, if a critical mass of usage could be reached and the site was trustworthy (i.e. not trying to monetize the information somehow).
I'm not sure this is correct, but I made a quick guess at which is the most representative Debian package for PCRE, and got this order of magnitude of direct and indirect dependencies for it:
$ apt-cache --recurse rdepends libpcre2-8-0 | tr -d ' |' | sort | uniq | wc -l
52160Looks like another example for Explain XKCD:
https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
https://xkcd.com/2347/
https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
https://xkcd.com/2347/
And thus a good candidate for funding from https://www.sovereigntechfund.de/ , should there be some trustworthy individual or group that could maintain it (I always felt like while this project is admirable, it should be regarded as a point of national security for nation states to maintain core infrastructure in-house)
Not mention of the music software:
> 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.
* https://en.wikipedia.org/wiki/Philip_Hazel
* https://en.wikipedia.org/wiki/Philip%27s_Music_Writer
> 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.
* https://en.wikipedia.org/wiki/Philip_Hazel
* https://en.wikipedia.org/wiki/Philip%27s_Music_Writer
My instant reaction to this was “Wait, is that PH10?”. Read the article, and of course it is.
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.)
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 met him briefly when I was at Cambridge in the late 90s. I can't remember why I did, but I do remember that he was an absolute legend back then.
> To date, he said he had received "no communications whatsoever" about taking over the project. Perhaps, once the word gets out more widely, a qualified maintainer will step forward to take PCRE2 into the future.
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.
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.
As the person that authored and maintained a fairly important (but obscure) project, for ten years, before handing it off, I can relate to this chap.
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.
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.
But how would you know?
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.
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.
Struggling to find it now, but one of the crazier scams I’ve seen was for an NFT company who was making, IIRC, cards.
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.
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.
> 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.
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.
Fair point.
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.
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.
Yeah no tinfoil needed, xz was exactly that, except sloppy. We won’t hear about a second attempt for a long time after it’s happened.
For all we know, intelligence services might have already had multiple successful attempts prior to xz so they just got complacent on that particular one.
The problem we have is you can’t prove the absence of something.
The problem we have is you can’t prove the absence of something.
I'll agree with thankless. But I'm confused about "pays peanuts," because unless you get hired by a company paying you to work on open source software, or have somehow cracked the code to acquiring extremely generous patrons (donations), I would say being an open source maintainer typically pays nothing at all. Which is fine for a lot of us who consider it a hobby and would never _want_ to be paid for it.
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.
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.
I totally agree with this but haven’t actually maintained any open source projects. Have you?
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.
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.
> [...] individual who feels they are sacrificing for the good of society [...] 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?
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?
"Turned" may be the wrong word. "Cozened" might be more correct. There may be no good way for an individual to identify someone who is being paid to take over their project from someone with a genuine interest.
> Open source maintainer is a stressful, thankless job which pays peanuts compared to what you could get for the skills and time
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.
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.
>Open source maintainer is a stressful, thankless job which pays peanuts compared to what you could get for the skills and time.
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.
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.
Someone should write an article like this about Edit Weitz.
https://github.com/edicl
https://github.com/edicl
This was great to read. I had never heard of Philip Hazel until today. Although I appreciate the work that he's done in maintaining PCRE, I hope that I am never in the position where I am still working on a project at that age.
I had never heard of him, but can completely relate.
I plan to pop my clogs at the keyboard.
The coroner is gonna have to rub "YTЯƎWϘ" off my cheek.
I plan to pop my clogs at the keyboard.
The coroner is gonna have to rub "YTЯƎWϘ" off my cheek.
> I hope that I am never in the position where I am still working on a project at that age.
"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!
"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 borrowed the title from a talk he did in 1999, but didn't find a way (mea culpa) to work that naturally into the story.
I do believe that, yes, he has enjoyed the work and "hijack" is employed tongue-in-cheek.
I do believe that, yes, he has enjoyed the work and "hijack" is employed tongue-in-cheek.
Yah I kept searching for a highjack connection thinking he got hit by malware or something like that. Never found it so I think you’re right.
What would you be doing instead at 80, if not working on a project?
Depends
:slow clap:
This is an interesting problem open source might start facing. There are a lot (I assume) of mature, critical libraries with a single owner. These libraries started their life around 30 years ago, and the maintainers are ready to move on. Taking on maintenance isn't very exciting since all the fun work's been done, but the open source world needs it.
That’s what I was thinking, too. There are some fun aspects but there’s also a lot of stress: if you fix a bug, what are the odds that someone added a dependency on that behavior in one of the thousands of dependencies which accumulated over the decades? Yes, tests are great but I’d still bet that your inbox would get more grumping than thanks until we can unbreak open source culture.
> unbreak open source culture.
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.
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.
No, but the part where people don’t make a distinction between how they view paid support contracts and open source is. “Uncompensated labor of others” covers everything from sneaking into a concert to reading an entire book at the bookstore to pirating a movie/game to buying an academic license for something you use at work to harassing an open source maintainer into adding a change you want. Since I only wanted to talk about the last one, I used wording specific to that.
https://xkcd.com/1172/
Are we sure this whole discussion can't be reduced to just links to xkcd strips?
Are we sure this whole discussion can't be reduced to just links to xkcd strips?
Picard and Dathon… at El-Adrel
> What particularly amazes me more than the CPU power is the amount of storage that I carry in my pocket.
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.)
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 find annoying that to this day there's computers sold with only 8GB of RAM
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
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
Software dev machines continue to increase in memory. I’ve seen some using 96 GB in laptops!
Ok that's a fair point. I've seen 128GB too but in desktop
That's the ultimate "works on my machine"
That's the ultimate "works on my machine"
Zoltan Herczeg, the jit maintainer is capable enough, and he is doing most of the work anyway.
Zoltan’s work on the jit is incredible. PCRE went from “venerable old warhorse” to “making a case that backtracking can still be fast” when the jit landed.
If I may interject for a moment, the software you are calling "jit" is actually pronounced Git…
[deleted]
I'd take this as a moment to celebrate a guy who's done a lot of great work without having his name bathed in limelight. Not a prompt to wring hands about succession or security bobbles in other people's projects.
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.
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.
"Here at Craptech, we love open source. We love that people will spend decades of their lives working for our company, for free."
> Now, he is ready to hand off PCRE2 as well, if a successor can be found.
My dear friend Jia Tan – although I hear they go by a different name now – might be interested in taking over maintenance of PCRE.
My dear friend Jia Tan – although I hear they go by a different name now – might be interested in taking over maintenance of PCRE.
> I asked Hazel, given the recent XZ backdoor attempt, how he intended to vet any prospective PCRE2 maintainers. He replied that it was a good question "to which I have no answer. I will have to see who (if anyone) makes an offer".
He’s clearly aware of the problem, so there’s that at least. It is a tricky one.
He’s clearly aware of the problem, so there’s that at least. It is a tricky one.
so this "clever" drive-by comment is the extent of dealing with the actual systemic situation.. while every person reading this is benefiting from the software, and some not reading this are trading stocks on surveillance software. "go buy some stock" is the next useful comment on this? FU basically?
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.