I have maintained popular edu source software (10k stars on GH - not crazy numbers, but still significant) these last 5 years and the experience has gotten better over time.
I am far more liberal in saying "no" now than I was previously. Typically when a user comes around asking for X, Y and Z, I'll ask them "do you want this enough to do something about it?" - most of the time the answer is no.
This is usually followed by something I see a lot in the open source community (but I don't entertain _at all_ as an edu source developer), some variation of "this is a deal breaker for me." or "but pwease this is the only thing I am missing!"
Ultimately I write software for myself, not for anyone else. I allow individuals to use it for personal use and to look at the source code to learn from it. That's it.
This year I started selling commercial use licenses to fill the gap for people who wanted to be able to use my edu source software at work, and my approach is largely the same; I am allowing people to use the software under certain conditions and that's it.
I'm not selling feature development, I'm not selling support, I'm not selling any kind of prioritization.
I work on the things that I want to work on, sometimes those things include ideas pitched by others that excite me, sometimes those ideas come from people who pay for a license or sponsor, but ultimately I always work on what I want to work on, just like I did when I was the only person using my software.
This could be bad for supply chain attacks. Basically the xz hack.
Step 1. Helpful person starts committing useful PRs and offers to help out until they get commit rights. I don’t think this is hard to achieve generally.
Step 2. Organised campaign of grumpy users complaining about how poorly the software is being maintained along with a bunch of pile-ons.
Step 3. Benign committer decides it’s all too much and quits. The general feeling that open source committers are undervalued makes this more likely.
Step 4. Supply chain attack by new evil committer.
So might it be useful to have some mechanism to check if the 'maintainer' (owner/principal committer/?? - what Peter Murray-Rust used to refer to as the 'Dr Who') changes?
Like, when bumping the version on a dependency, the security system could check if the maintainer has changed, then you could go and double-check any changes.
my general sense is that the financial party is coming to an end and with the trump/biden/trump flip flop a lot of people are at least on edge if not actively hostile, and that negative energy is flowing into open source like everywhere else
the problem is that most open source is based in large part on goodwill, and when that goodwill evaporates it becomes much harder to maintain motivation
people sometimes criticize how unserious the "marketing" (sic) of htmx is but there's a good reason for it: I enjoy the humor and having fun has been a key part of the motivation for me to keep working on the project, and dealing with the inevitable negativity.
“I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun.”
Computing has all but been drained of its fun. There are pockets trying to retain it, but it gets harder and harder.
A real life example in closed source development in a tech company that I experienced directly...
A team organically chose a cute mascot animal and started doing things like bringing in stuffed animals of that animal and including visual puns involving that animal in presentations. The manager leaned into it, which caused people to find even more ways to have fun with it. As the team grew and split, it became the mascot of the group of teams. Some engineers got together and wrote a short graphic novel explaining the emergence of the mascot in the group. Eventually one of the engineers designed a logo for the group that was a cartoon version of the animal and subtly incorporated the group name into it (the name was almost an Easter egg that had to be discovered, it was very clever). Stickers of the logo were made and given to new engineers when they joined the group. People would use "where did you put your stickers?" as an ice-breaker to have a first conversation with new people. Reserved people who were hesitant about giving presentations were encouraged by getting laughs from their visual puns. It was all very silly, but it made a lot of people feel included in the group soon after joining, opening connections and fostering better communication / collaboration. Highly tangible benefits were easy to spot. This lasted for the better part of a decade.
When the leader of the group (the original manager that leaned into it) left that role, the new leader viewed all the silliness as a distraction. He didn't explicitly kill it, but he did lean away from it. He never included any references to it in his presentations. When asked to reimburse a batch of stickers for new hires, he said the company can't waste money on things like that (less than a dollar per new hire). He spent hours removing all references, usually in the form of textual puns, from documentation. In a year or so, the mascot was relegated to nostalgia. New people were no longer meeting as many people in their first week and cohesion suffered. There was less fun in general. It was a big part of the group's culture becoming much more sterile and detached. When asked about it, the new leader proudly called that sterility "professionalism". A lot of people that had been in the group for many years called it "one less reason to stay".
Years after the mascot faded away, there are still group dinners of ten or more former employees of that group, that happen multiple times a year. A recurring topic of discussion at those dinners is how to find a place to work that is so motivating and has such great teamwork. The silliness and simple jokes around that mascot were a big part of what made that group so cohesive. In fact, they were both a symptom and a cause, creating a positive feedback loop that helped build and maintain the group's culture.
Off topic, but this is what bothers me with current macOS or Windows UI design: it is sterile. It's not nearly as fun as, say, Windows 7 (or XP!) or pre-flat macOS.
It's very easy to move something from fun, vibrant, exciting to flat, boring, and sterile. It is _very hard_ to move it the other way, because of concerns about professionalism, where professionalism is seen as sterility and the safety that's in that sterility. I think UX needs _joy_... would you agree, are you and I and the parent poster are saying something similar about different aspects of computing / software? I wrote an article on it here: https://daveon.design/creating-joy-in-the-user-experience.ht...
Yeah, I agree that this is all related. Especially the safety part. All of the overlapping domains we're talking about here are at their best when creativity is unleashed. Sometimes that means failed experiments (uh oh, danger!). But it's also where we get big leaps forward. Managed properly (e.g., doing the hard work of learning from and addressing failures before they do too much damage) can lead to a much better average over time.
I think this is all analogous to the conditions that give us bland TV commercial jingles vs. the conditions that give us great music.
The second half of that quote is often omitted but I would argue is as important as the first:
"Above all I hope we don’t become missionaries. Don’t feel as if you’re Bible sales-men. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands I think and hope is intelligence: the ability to see the machine as more than when you were first led up to it that you can make it more."
I've seen a lot of people in this community be dismissive of those outside if it except when they can court them as customer. I think this is a mistake. I would argue that we hackers are the vanguard of technological progress (well, as far as computers and electronics are concerned), but the vanguard isn't the only part to be concerned with. There is the long tail of everyone else who finally get the refined, consumer result of the prototypes we hack together (either for our employers, the company we found, or the things we sell independently). We need to understand that and make sure their needs and their safety are kept in mind while working on things.
You'd be surprised what people can learn and what changes they can make if they have a safe space to do it in and they have the confidence that if they make a mistake that it's not going to end in catastrophe - either financially or physically.
In the early days of computing there were several European chip companies which competed with Intel. The Acorn RISC Machine (ARM) processors that are widely used today were originally designed in the UK in 1985. For better or worse, chip design and manufacturing is tremendously capital intensive so you have to focus on money to make it sustainable over the long term.
First principles come to mind here. What does compute even mean? Understand a problem and finding way to calculate a solution to it. In modern days, this means digitialization of analog reality. Discrete and replayable patterns of sequences, creating automation and intelligent automata.
How could that never be fun? When money is the driving force.
With all due respect to Alan Perlis, he seems to have mixed up Computer Science with Software Engineering. Those are different things. There is generally somewhat less room for fun in engineering disciplines (although not zero).
Maintainer burnout is certainly one of the memes in open source at the moment. I suspect that some of it has to do with various pressures at commercial software companies these days that make it harder for developers trying to carve off some time on the side. Overall increased dependence on open source software generally also probably plays a role. If your job depends on some upstream bug being fixed, it increases potential tensions.
I developed a couple open source projects that my startup used and got some small adoption.
I was essentially unable to maintain them using company resources after we were acquired last. Telus had no open source strategy for giving back at all. Not even on projects they "owned". I'm sure it's similar in quite a few large companies.
> If your job depends on some upstream bug being fixed, it increases potential tensions.
Same problem with commercial software: if you need a bug fixed asap there are not a lot of solutions. At least with open source software you can fork and fix while waiting for the upstream resolution. But you can also go the commercial way of doing things: contact their sales dept and shell out what they're asking for to prioritize your problem. I'm sure some open source maintainer would be happy to make your bug their next priority for a big enough payment.
> Same problem with commercial software: if you need a bug fixed asap there are not a lot of solutions.
I purchase software for MacOS, and whenever I've contacted developers about a bug, they've usually resolved it within a few days at most. If I submit a bug report for FOSS it gets ignored for years at best.
Why is there an expectation that a bug you filed against an open source project should get resolved? If you expect a solution there usually requires that you take some effort and contribute. In larger projects there may be more interested parties that are simply looking for work (eg college students trying to build a resume), but maintainers themselves are not necessarily obligated to fix your problems. I very much hope it becomes the norm that all filed bugs should have bounties associated with fixing them.
Projects vs. products. There are commercial open source-based products (e.g. from Red Hat that I used to work for) that have the same sort of support that other enterprise software products have. And there are the upstream projects (that Red Hat contributes to and interacts with).
There is no expectation about contributing to open source products other than paying money to a commercial provider. There are a variety of reasons why you may benefit from them being open source-based but they don't come with any particular expectation of contributing upstream directly as a user.
Purchased software presumably has some level of dedicated support staff whether the primary developer or something else. I don't expect someone who developed as a hobby to be "on call" or to prioritize a request--and it may be pretty inactive in many cases.
That's what's great about it. And if a paying customer gives feedback, you already know that they represent an important user segment that are worth listening to: Paying customers.
When I did shareware, I did have some pretty dedicated beta testers who were good sources of input. It wasn't the money--heck, they payed me something like $15. But, yeah, I agree in general. If you're a business the feedback of paying customers is pretty much what matters.
Not a lot but you pretty much always have the option of engaging with consulting. $$$ of course. If it's really a bug rather than some sort of fork, not too bad. Presumably the bug will simply be fixed, albeit prioritized. Otherwise not clear if your different use case will be maintained other than in maybe a customized way.
It is easier with open source though also albeit not a perfect solution if you're out of the mainstream.
>his employer gives him four hours a month to work on the project.
That is considered good ? I guess much better than most employers, but if it was 4 hours per week, then I would say that is great. I am sure the employer uses lots of open source programs :)
Given all the efforts to produce SBOMs, it would be really nice if companies used them to pay a tithe to their dependencies. None will, of course, because companies love getting all that software for free.
Open Source projects could sell SBOM fragments with correct licensing information.
"Instead of scanning for copyright notices and license texts yourself, just sponsor us on GitHub and get access to always up-to-date SBOM information by the people who really know what‘s inside“.
At that point (or preferably before) they need to pay attention to exactly what they're getting, including warranties (if any) and what paid options are available to get what they need or want.
> If the dependencies wanted to get paid they should not have given their work away for free.
That’s not really a reasonable position. Nobody signs up for maintaining a library that most of the Internet depends upon with megacorps beating down their doors for an unpaid P0 fix. “They gave it away for free” doesn’t mean they are your eternal slave.
Tech companies are cheap as shit and most programmers are very subservient. Open source won’t go anywhere, I’d bet in there being more open source projects than less in a years time.
Open source only makes sense if you are either paid to do it or all of your users are able and willing to submit high quality patches. I've seen this phrased as open source is good for platforms and infrastructure, but bad for products. Open source as a product inevitably seems to lead to unhappy maintainers.
I am far more liberal in saying "no" now than I was previously. Typically when a user comes around asking for X, Y and Z, I'll ask them "do you want this enough to do something about it?" - most of the time the answer is no.
This is usually followed by something I see a lot in the open source community (but I don't entertain _at all_ as an edu source developer), some variation of "this is a deal breaker for me." or "but pwease this is the only thing I am missing!"
Ultimately I write software for myself, not for anyone else. I allow individuals to use it for personal use and to look at the source code to learn from it. That's it.
This year I started selling commercial use licenses to fill the gap for people who wanted to be able to use my edu source software at work, and my approach is largely the same; I am allowing people to use the software under certain conditions and that's it.
I'm not selling feature development, I'm not selling support, I'm not selling any kind of prioritization.
I work on the things that I want to work on, sometimes those things include ideas pitched by others that excite me, sometimes those ideas come from people who pay for a license or sponsor, but ultimately I always work on what I want to work on, just like I did when I was the only person using my software.