Hacker News Reader

Comment by jwells89 | Hacker News Reader

This blog post indirectly touches on one of my most frequent (if potentially unfair) gripes with FOSS projects, which is how few of them have a culture of polish and user-friendliness.

So many of these projects seem to try to do as many things as possible somewhat passably instead of doing a handful of things really really well, and this is often not only what pushes me to use proprietary products instead but also disinclines contribution, whether that be by way of code or donations. If I try to contribute code, project misalignment with personal values is going to make getting PRs/patches approved a constant battle, and on the cash side of things it's hard to justify spending on a project I may never find usable.

This means that the number of FOSS projects I contribute to is much smaller than I'd prefer it to be.

View on HN

Don't just go into blaming culture.

Everyone should accept that is just super expensive to do good software. Money help, but it is also expensive in terms of focus and time. Having team of developers/business analysts/QA focused on one project is loads of money.

Even for small team like 5 devs, 1 QA, 1BA - let's say every team member gets roughly $6k a month that is like $42000 a month. Now question is how many features/fixes can you do with that team? Well form experience you get maybe 8 big features, where big feature is like 2 weeks of work for a developer back and forth from QA and getting clarifications from BA, you have 5 devs but in reality there will be no 100% alignment and you still have bug fixes, busy work etc.

So $42000 divided by 8 gives that any feature costs around $5250 to build initially and still might be having bugs and need for adjustments. But you have at any point in time at least 3 people looking at the feature and making it work/finished.

Now we can talk about culture where companies throw $5k at a feature on a whim, burn everyone's time with useless meetings on VC fueled life support compared to FOSS where budget for a feature is more like $1k of whatever spare time some dude somewhere has and he is "making the feature up, coding it and testing" in most projects on his own.

> making the feature up

This is super hard, often someone will write a mindless issue with a feature request without thinking about it profoundly.

Than the dev has to sift through the text to understand what is the underlying problem the user is facing, if the proposed solution is actually a good solution to that problem (it often isn't), what is a solution considering long term maintenability, if the feature has synergy with future features or if it solves or is close to solve other already existing issue so the solution scope should be adjusted. The design stage is huge and it's hard to do alone and also hard when other contributors only raise edge cases to try to break a proposed design without validating if the problem the developer extracted is adequate. The scoping and design is often very time consuming and hard to get it right. Usually you end up designing to the scope of available time to solve the issue at hand - time being a rainy Sunday afternoon, or around three and half hours.

Which is why you can be entirely helpful in an open source project even without knowing how to code. If you can learn the general program, and interface with the users as a liaison between the developers and the bug tracker, it can be quite valuable.

As a product designer, I naturally agree with this, but... are there any instances of this actually happening?

I suppose there's Blender, but it's kind of a special case.

I’ve seen it a few times and done it myself more than once, mostly smaller projects

Blender is fairly amazing as a case though. I know it has a foundation and a lot of monetary support there. But I guess it didn't always?

Also there's the possibility to help in writing documentation.

The question there is why you're operating using teams of 5 devs. The most productive environments I've worked at were ones where single devs had ownership over a chunk large enough not to require that much interaction (IE an amount of interaction that you would contemplate between teams, not between devs on a team)

The issue with that is that you have to eat a big handover cost when people leave. But these environments had great retention and long contractual notice periods, so it wasn't a huge issue.

IMO the "two pizza team" isn't as productive as people think.

How did oncall/operations work?

The companies where I worked like this didn't run services, they shipped releases. Which is how open source stuff generally works, although the income part can be a service (but not always)

I am in a company where most of us are "experts" of one part of the system. This is very stressful (because when there is an emergency related to my part, I am the expert on whom management is waiting), annoying at times (because nobody cares about my part, they have their own stuff to do, so it's hard to share), painful at times (when I'm struggling, I don't really have colleagues who can help), and annoying again when someone is on holiday and we need a change in their part.

Agreed on the handover cost, though (obviously).

Not saying that 5 devs are required, but 1 is not always the nicest IMO.

Fair comment - I'm not saying it's a panacea. Just that it's productive.

Having one person that knows everything about some system is great, until they get hit by a bus.

Writing new features is fun. Polishing is boring and thankless, aka work. Most people will do fun things for free but want to be paid for work. Probably not going to change anytime soon.

Writing is fun, polishing is boring but ok, merge politics is like burning in the pits of hell. Same result.

Sometimes getting a contribution into a FOSS project is more difficult than proving your application will halt.

And for good reason. If you swoop in and add a feature I (as the maintainer) don’t care about, the maintenance burden for that code usually falls to me. I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about. So yeah, I have higher standards for testing and code quality for 3rd party contributors than I have for my own code. I like PRs which fix bugs. But PRs which add features, without talking them through first? Ehhhhh

Sure, but that's why I mentioned politics -- the particulars matter and there is plenty of ground for reasonable people to disagree.

Judgement goes both ways. Maintainers are under no obligation to accept my code, but if enough maintainers stonewall enough of my code for reasons that I consider unreasonable enough then I'm under no obligation to write the code, either. That's where I've gotten to. It wasn't a short journey. Oh well.

Yeah. I think deep down opensource doesn't rest on the ability to make pull requests. It rests on the ability to fork. I think maybe people should do that more often.

If you add the missing feature to a fork, nothing stops you from making use of that code directly. You aren't dependent on the author merging things upstream. You never were.

>I don’t want to spend my time maintaining someone else’s code for a feature I don’t care about.

seems like a self furfilling prophecy, no? if you don't care about the feature but also make it impossible for others to reasonably enter and care for you, all you're left with is a broken window.

Maybe the onboarding is the real issue. There aren't a lot of people around who can dedicate themselves to simply educating new contributors (clearly the "educate yourself" approach doesn't work, based on your experience). the maintainers are too busy to do that themsevles most of the time, so that means it's another dedicated position to fill.

But alas, no one wants to pay for teachers. Teachers don't produce immediate value but are being immediately paid. How wretched. Even tech isn't immune to such philosophy.

> if you don't care about the feature ... all you're left with is a broken window.

Maybe. Or maybe I'm left with a building that works fine for me. It might be lacking some features that some people want, but maybe thats ok.

> Maybe the onboarding is the real issue. ... the maintainers are too busy to do that themselves most of the time.

Yeah; I saw a great talk from Strange Loop the other day by the developer of Elm on the economics of opensource software[1]. He pointed out that a "good" opensource project really wants good dev work, a maintained issue tracker, infrastructure (CICD, etc), a good website, documentation, blog posts, onboarding of devs, community stuff, conference talks, trademarks, a roadmap, and so on. But it takes more than one person to do all of that. It takes a whole team.

And we're spoiled by opensource projects like React or Rust which are sponsored by companies with money. My little opensource projects just have me, in my hobbyist time. And I'm not very good at all the non-programming things. And I'd much rather be programming than doing all of that other stuff.

I think a lot of projects really want fulltime maintainers. But instead they just have the unpaid, overworked authors doing what we can. Of course users want better. But, well, thats how it is at the moment. Honestly, its surprising that everything works as well as it does.

[1] https://www.youtube.com/watch?v=XZ3w_jec1v8

>It might be lacking some features that some people want, but maybe thats ok.

that's fair and respectable. I'm never going to harp on a volunteer for "not working hard enough".

But we can also apply the same logic to projects like GIMP. It's still active so it's not like they haven't heard the decades of feedback on UI/UX.

>And we're spoiled by opensource projects like React or Rust which are sponsored by companies with money. My little opensource projects just have me, in my hobbyist time.

I think most of the criticism comes from the larger projects that have those maintainers but act as gatekeepers against project. Of course I'm not going to hold it against a small repo maintained by 1-2 people if they don't merge in all the PRs. I'm more likely to simply fork the project if I really need it and maintain my own specific fixes/enhancements in those cases.

I make open source code for myself. I've done several minor "contributions" to different open source projects.

Three examples:

- Linux mint start menu isnt able to perform basic numerical computations. I made some simple changes to be as ble to do that, and made a PR.

- A Mint desklet showing pics didn't show the file location, I added that functionality. Pr done as well

- A Mint tray icon Applet for crypto was missing some functionality I wanted (dont remember what). I added it and made a PR.

The first two PRs were rejected for whatever reasons. The last one was accepted and merged.

I couldn't care less about the first two, I made the code for me and it works for me. I just put it there in case the owners found it useful. If not, I dont care.

Nobody is getting paid to do open source, there may be people who like the "fame", but myself? I just want to solve my problems.

But solving your problems is easier if your patches are merged, less maintenance burden on your future self

> there may be people who like the "fame"

it's more for the sake of "pay it forward" in my head. if I think a feature or fix will benefit others, of course I want to share that. But if the gatekeepers don't care or see eye to eye, I'm not gonna spend hours arguing over it.

If its a minor enough add/fix, I'll simply point others to the PR to grab themselves if they hit the same issue as me.

>myself? I just want to solve my problems.

maintaining my own branch adds more overhead when updating though. Not enough to go through the politics, but enough for me to at least try to throw a bone at Main first.

And that's totally fair, but at the same time something of a catch-22. The most well-funded FOSS projects (and thus, those one is most likely to be paid to work on) are generally those that are more polished. What this means to me is that projects need to have a very focused featureset and polish culture from the very beginning to kickstart the virtuous cycle.

it's also a lot to do with the types of people that do polishing/artistic work are very different people from those that do the programming of the features.

expecting an artist to be a good programmer or a programmer to be a good artist is just unrealistic. not a lot of artist attracted to FOSS/github/projects to go looking for things to do. probably a much better result from FOSS maintainers to jump onto Fivr and look for someone to do polish

> not a lot of artist attracted to FOSS/github/projects to go looking for things to do

It happens sometimes but the aforementioned difference in mentality usually ends up with those artists giving up and moving on because of the friction involved.

a healthy paycheck seems like the only thing that allows the two to work. and a shit load of managerial layering to run interference and cross-translate requests from either side.

jwz dubbed this "CADT programming"

There is a secondary issue: Even on projects where someone is interested in doing polish work, since it usually takes longer to polish than to write a new feature, those who only care about writing features cause the backlog of things that need polish to grow infinitely.

I don’t really know of a good strategy for dealing with this in FOSS. If a feature contributor doesn’t care about polish, and you say to them ‘please fix the UX’, they can just either ignore the feedback (‘perfect is the enemy of good! move fast and break things!’), or if they don’t have direct commit access, create a fork that they can then advertise as having lots of cool new features.

I would love to know some strategies that work to strike a balance between not demanding perfection and not allowing garbage to be mainlined.

This is why I mentioned keeping a smaller, more focused feature set in several of my comments. Polish is much more attainable when features aren't being added as frequently.

That has to come from the top of the project's management though, since they're ultimately the ones responsible for policy and enforcement.

My approach would be as I mentioned elsewhere: allow those wanting to contribute new features to do so, but make it clear that these features will be present in prerelease builds only until their quality meets the project's standards.

I actually love polishing but not writing tests unless it’s with cypress.

I don’t mean to be snarky but you really just get what you pay for. A lot of FOSS is produced by people for fun, to solve a specific problem they have, or to learn/play around with some technical concept. Unsurprisingly, people don’t want to do the unfun things like deliver a UX that’s intuitive even for those who don’t work in the thing, or handle support, or play TL/EM/PM with randoms on GitHub.

I feel like my optimism for FOSS software has slowly degraded to nothing. GIMP will literally never replace Photoshop and the gap between them is only growing. How can a product that's raking in millions of dollars a year ever be replaced by a few people working on it in their free time?

When software was simple and if companies were just sitting still without continuing development, maybe. But most companies seem to be full steam ahead pumping everything in to research and development.

Photopea seems to work really well for a decent subset of what Photoshop does.

Never heard of that one, so I was interested and checked it out. Turns out they do have a github repo but it plainly says: "Since Photopea is not fully open-source, this repository serves as a place for bug reports, feature requests, and general discussion."

Looks like a nice product, but I would not consider it a FOSS alternative to GIMP.

Photopea is not open source. I think it's still made by just one person, but its ads bring in a lot of money.

There are excellent projects like Blender which proves that high quality FOSS products can be done.

Check out some of the names on fund.blender.org

I think a lot of people have this misconception that FOSS is produced by volunteers working for no pay. I mean, they don’t literally think that, but they bucket FOSS produced by amateurs and volunteers with FOSS produced by companies with massive R&D budgets. The only thing those software have in common is that they are free to use and modify as-is.

In some cases, FOSS is literally just something a company made to meet their needs (in a way that mostly generalized it) and then decided “hey this would be cool to donate as FOSS.” Blender and Linux are also basically paid software, they are just funded by the many corporations who rely on them. You can’t compare that to abandonware some guy made in his free time or volunteer-produced software that competes against software funded to the tune of billions of dollars per year.

I think there are two competing truisms at play when comparing paid software to acceptable-ish FOSS software in the same space.

One is that funded software is almost always going to be more polished and easy to use than unfunded software. The vast majority of successful FOSS projects are either funded by corporations directly or by nonprofits which usually are still getting most of their contributions from corporations. True volunteers have no incentive to fix your bug or provide support.

Another is software provides diminishing returns the more it’s invested in past the point of viability. That’s partly because 95% of people need from the software comes from a small set of important core functionality, with the remaining 5% coming from everything else, but the 5% differing from person to person. Chasing that last 5% is not only very expensive and time consuming, it adds a lot of complexity and overhead. So there is a lot of FOSS that only solves up to the 95% point because it’s not too difficult and the people maintaining the FOSS have a different 5% than you do.

Anyway, it may not be the case that all software will be FOSS any time soon and GIMP will replace photoshop, but I certainly wouldn’t consider GIMP a failure. If you just need something basic and free for some light editing it works fine. It’d be a shame if people with simple needs had no free alternative to expensive licensed software.

Related to "the 5% differing from person to person":

> A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

> Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.

Source: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

>How can a product that's raking in millions of dollars a year ever be replaced by a few people working on it in their free time?

You don't directly compete. figure out a pain point and make your smaller product focus really hard on fixing that pain point.

You won't have an industry migrate to you, but you will attract some audience, and maybe that audience can start influencing Adobe to get that into their own tooling.

>But most companies seem to be full steam ahead pumping everything in to research and development.

well, they were until... March or so. I guess now's a good a time as ever to catch up if that's your goal.

The way FOSS works engraves feature abundance - every contributor has some feature wish that they will add - most of them jumps on the project for that very feature. Both contributors and target audience values features and configurability, and "unpolished" parts (mostly meaning you need to click 2 submenus more, you need some config to be set or script it yourself) are not a problem. This is the very antithesis of a for-profit company being laser focused on some customer group and wanting to be cost efficient with resources.

Lack of polish also extends to some of the things like the TFA mentions, like incomplete SVG export functionality.

Either way, I don't believe that polish and FOSS feature abundance necessarily have to be at odds; it just means that the project in question needs to have a process for developing new features to production-readiness. This can take form in any number of ways, for example using feature flags to keep things that aren't yet fully baked enabled only in beta/alpha builds — people happy with a less polished experience can use betas until the feature they need is ready for primetime while the greater userbase gets a better user experience.

Kind of agree, kind of don’t. A lot of companies also bolt on as many features and integrations to their products as they need, to close sales or just because they think it will help expand their potential customer base. A lot of FOSS is maintained by people who don’t want to spend their free time shepherding some code they wrote turning into everything-software either.

There is a particular failure mode in FOSS though - normally in businesses, prioritizing new features is done on the basis of how it will ultimately affect revenue (or reduce costs, simplify things, reduce maintenance burden - still money at the end of the day). For those FOSS projects that are open to new features from randoms, those individuals are mostly adding features they individually want, and the amount of investment in those features is limited mostly by their level of personal interest. So you end up with a set of features that is more stochastically chosen, and some unimportant or minor features may have a huge amount of complexity/configurability/feature-specific code because one person needed it.

Polishing is expensive, and while you're doing it you're falling further behind on feature parity.

The fact is that OSS simply can not compete with multi-billion dollar companies with enormous staffs that give away their server time for $0. There aren't enough human hours to go around.

Figma has ~1000 employees last I checked, and Adobe has nearly 30k. Orders of magnitude larger than most OSS projects.

So a lot of the time in OSS you end up choosing the work that keeps people interested (because often you don't have the money to do so). Developers want to build new features, and designers have next to no interest doing free work for OSS.

It's not really about culture. Everyone – OSS or not – wants to write good software. The problem is that the "polish" you mention is what takes up the vast majority of development effort and costs, and FOSS projects just aren't that well funded. Hiring teams of designers, copywriters, user researchers and HCI experts, staffing up customer support teams in different timezones, having dedicated QA for every minor change, overprovisioning servers so the app can scale...none of these come free or easy.

It's the last 90% of the work that takes 400% of the time.

...meanwhile, more than a few people on HN think all software should be FOSS and proprietary software is evil.

It should, just well funded, like Blender.

Devs do free work for the world and hand it out as FOSS. UX people feel no compulsion to do the same so that's why we have the current state of things.

These are two separate skillsets that often don't overlap, you won't find many UX people contributing to open source projects.

wonder why dev culture is so vastly difference from other sectors in that regard. I guess it's because tech is arguably useless as-is except to other experts. And even an expert may struggle whipping up a competitor from scratch (i.e. not copying the code unless allowed). Whereas even the layman can see "good" art and "good" UX.

But it's also not universally true. the acedemia sector of tech doesn't really open source stuff in the same regard. They may have some readable source, but you generally can't use it commercially without consulting the owners. I guess patents change a lot of how you work.

First, I would like to suggest that you take a step back and think about how many non-FOSS projects are complete failures even though a ton of money was thrown into them. So yeah... there are good, average and bad FOSS projects just like there are good, average and bad proprietary projects.

Then, you have identified some characteristics of FOSS projects: some do tons of things somewhat passably (that's typically the case when the maintainers try to accommodate the contributors), some don't do much and don't get many contributions, some don't do much and just refuse contributions that the maintainers don't care about, etc.

But you have to understand that maintainers don't all have the same goals. I don't know if you have ever been a maintainer, but users can be real jerks. Almost blackmailing the maintainers ("if you don't implement this feature I won't use your software for free"), sometimes even being aggressive ("this project sucks, I spent 2 days trying to understand how to do that, if I had a choice I would use something else but I don't want to pay"). Almost nobody says "I will pay you to implement this feature properly and I don't expect you to maintain it for free forever".

It's hard to be a maintainer, and if you manage to do a good job and went for a permissive license, chances are that people (companies) will just use it without contributing anything back (not even honoring the attribution clause, because 99.999% of people don't understand that permissive licenses require attribution).

IMO companies would have to contribute much more if everything was copyleft (at least MPLv2).

I don’t think a FOSS user facing product can actually work well. The ones that I found that worked very well (aesprite) actually just seemed to be founded by a single team that barely had any outside contributions. Basically they could’ve gone proprietary.

And I think it has to do with the nature of humans actually. Those in a company or team feel part of the tribe and are more than likely to feel good when they contribute. While a random person looking to contribute into some FOSS project would see it as some mountain.

Unsurprisingly, the first 90% is a lot more fun than the "second 90%" (polishing)...

In my experience It depends on the kind of software you're talking about. If you mean especially GUI-heavy apps like Office/Libre Office Gimp/Photoshop FreeCAD/AnyCommercialCAD KiCAD/Altium yes your criticisms are valid. Mostly for the reasons others have said already.

However, consider other types of software with minimal gui for example Apache-Nginx/IIS, VisualBasic/Python, command line tools like awk, sed, shells like bash vs cmd. Lots of stuff.

It is a fact of life an Open Source model works better when no GUI is involved. Why? Because many people including myself find it mind numbingly boring and difficult at the same time to come up with a good, usable gui.

I bet there are at least 3 startups in the dark somewhere in the world working about AI generated UIs right now. If they succeeded that might be the thing OS software needs to be better.

It’s a bit tangential, but I find that how much I enjoy designing UIs depends a lot on the UI toolkit I’m using. With many, it’s as boring as you say, but there are a handful which have a large repertoire of capable, flexible widgets and designer program that makes the process something of a joy. AppKit on macOS is like this. Qt Widgets has a lot of the right ingredients but somehow misses the mark.

Don't underestimate how much headcount is pouring over an array of analytics tools and split testing tools to optimize a commercial product compared to FOSS. For every dark pattern change that is made in a commercial product, perhaps 100 actual improvements/polish changes are made to workflows.

Though imagine how much more features and improvements that commercial product would have, if most or all of that headcount pouring over analytics were retasked to design, development, and actually talking to the users (or $deity forbid, shadowing some users to see how they use the software).

Other than being more careful due to software being sold on physical media, I wonder if that wasn't the lost secret source of software in pre-webapp times.

Those teams also usually exist. But usually different skill sets.

Ultimately, you have to have agency. The world is made by people who make so if you want something there's only one way to guarantee it: make it yourself.

If you don't want to make it, maybe you're lucky enough that there's a market and you can buy it.

But that's the deal with much of this stuff is that there's no polish because the builder didn't need it.

But that's not universal. I think many of BurntSushi's products have great polish and a good dev experience.

FOSS doesn't have polish because the original devs plan on selling the polish

which OSS has done this?

Jetbrains

in some cases this may be true, is false as general claim

$FOSS_Project description: reproduces a couple of features of well known applicationX

$FOSS_Project description: reproduces functionality of applicationX

how many people will be attracted to the first option vs the second?

Does it matter when the latter of those two turns off and loses the additional users it gained from the more enticing description because it’s half-baked and unpleasant to use?

Intuitively I’d think the former has better long term prospects, because it’ll have word of mouth (people love talking about things that make them happy) eventually make up for the reduced initial interest.

maybe a lack of clarity in my example. i'm not saying the same project with 2 different descriptions. if one project wants to be specialized in a small set of features while the other project is being a much more well rounded set of features to directly compete with an existing well known program, i'm proposing that the full program will garner more attention.

most people want a complete package. the masses don't think in unix-esque terms with small specialized tools strung together. they want to go to wechat/facebook/etc where everything is in one place.

> my most frequent (if potentially unfair) gripes with FOSS projects,

The difference is that you should not have any gripes with FOSS projects because they don't charge you anything, make no guarantees, and don't expect anything from you in return. In other words, your thoughts are irrelevant.

If you want something that works, pay for it.

If you want to play around and sometimes get stuff done, use FOSS. There's the exception for FOSS supported by big businesses, but this is not what people talk about when they talk about FOSS.

> If you want something that works, pay for it.

That’s literally what they’re doing, with proprietary software.

He can invest time/work or money. If enough people are willing to pay someone will offer it and he can pay. If not he has to write it himself.

Assuming such contributions are accepted in the first place, which is far from a given. It's not unusual for "polish" sorts of contributions to be refused by project maintainers for various reasons. It doesn't matter how much code I write or how much money I donate if the project has decided it doesn't care about the same things I do.

Of course I can technically always fork or start my own project, but that increases expenses by an order of magnitude, which I might not be able to afford.

I can't tell if this is meant to be defending FOSS or condemning it.

It's not meant to be doing anything. I have no vested interest in others hobby projects. If they want to polish it... great. If they don't... great. No one is entitled to anyone else's labor. This is not an argument in favor or against; it's a simple ethical claim on ownership and labor. If someone gives you something for free, you should be grateful, but would otherwise need to decide on your own whether or not you need to use it.

FOSS is like those canvas bags they hand out at conventions or at Costco. It's nice they're free, and the ownership model is straightforwards. Sometimes they're nice, sometimes they're not, and sometimes I need them and sometimes I don't. I'm grateful to those who give it to me, but if I don't need them I kindly hand it back. If I do need it, I use it. And sometimes, if it's not working out, I buy a real bag.

None of which means that you're not allowed to have gripes.

Yes, yelling and getting pissed at maintainers for not having the feature you want is counter-productive. But all OP did was outline some issues that have pushed them away from contributing to FOSS projects as much as they'd like, and you reacted as if they were demanding free labor.

Reply on news.ycombinator.com