If you've ever wondered why people say tools like Scribus aren't ready for professional production work let me share this blog post by @davidrevoy

This should be a slam dunk. David knows what he's doing and One Bookshelf provides instructions that clearly show how to produce a PDF to their specifications.

We need to do better, folks. Color Profiles that work for everyone except FOSS tools are unacceptable. Period. There are no excuses for this.

If you want FOSS tools to still be the "I pay for it with my time because my time is meaningless" then we don't need to change a thing. Keep on making it so folks have to play some perverse roulette to ensure that things work with outside printers and publishers.

But if we're ever going to show that we're just as good as the professional tools then we need to start emulating all of the imperfections of those tools. Specs be damned, if everyone else figured it out so can we.

I've seen this with other independent creators where they use Scribus to print their book, only to get a mangled proof back that takes longer to sort out.

You know what they did to solve the problem? Did they file bugs and wait for patches? Nope. They bought InDesign because Scribus lost them over a month's worth of sales and they couldn't afford to keep puttering around with Scribus to make it work.

This is why professionals say FOSS tools like Scribus aren't ready for production work. Until it's fire and forget every recommendation of FOSS tools is just someone saying "please use this thing to satiate my religious convictions and pay for it with months of your time and missed income".

The nice ones tell you no.

@craigmaloney I stopped giving full-throated FOSS recommendations ages ago because of this. "You use Linux! Should I?" "uhhh how much do you like configuring things to almost work?"

@craigmaloney Fair points, though there are plenty of equivalent examples from the proprietary world.

What I appreciate about Linux / FOSS is that, _with a curated set of tools_, 1) things work and 2) they tend not to regress bugs (not perfectly, but usually).

The amount of sunk and lost effort I've put into proprietary solutions is ... large.

Leading proprietary tools don't follow, but set, standards. Bugs are spec.

That said: headline / keystone FOSS projects *should* get their shit right.

@dredmorbius @craigmaloney i think the harsh reality is also just that it's a lot easier, economically / resource / person-hour wise, for FOSS tooling to be suitable for professional use in realms where a huge number of programmers spend their working days.

like a lot else in software, this is fundamentally an economic problem. we're unlikely get libre tooling that can compete with adobe until we have a good answer to making a living working on the stuff.

@brennen That's a definite factor.

Another option is for a particular entity which is on whole a *consumer* of a specific application to invest in its development. That carries all kinds of conflicts (free-riders, competitive advantage / disadvantage, etc).

In practice, a government entity _might_ find this to be worthwhile. Though those are subject to influence from commercial interests.

#HardProblems #BigProblems


@dredmorbius @brennen I think the first thing we need to do is stop trying to figure out who is at fault here, stop making excuses, and fix the tooling so it does work. Until then we're just creating tools for enthusiastic hobbyists and organizations.

@craigmaloney So much this.

"Blame" is a concern where there's some sort of legal liability.

"Cause" is what you should look for in a technical issue (even where the technical issue is social).

Identifying _what_ goes wrong, finding the biggest source(s) of frustration, and addressing or mitigating those, then moving down the stack, gets results.

Identifying processes/procedures to avoid / address issues preemptively.

A current bugbear: improving projects' awareness / insight.


@craigmaloney There's *still* a huge issue with issue tracking, submission, resolution, and communication systems. And this is hardly specific to FOSS -- dealt with problems with Google, Reddit, Comcast, or your healthcare provider recently?

If anything, FOSS has improved tools (Bugzilla, GitHub/GitLab, etc.). They're still not good enough, and scaling is hard.

James Scott's "Seeing Like a State" has much relevance here.


Note that if you're a proprietary de-facto standard application, then subtly fucking up your compliance to spec is actually good for business, as that'll make potential competitors look bad.
@craigmaloney @brennen

@pettter @dredmorbius @brennen Mind keeping this conversation to actual issues that can be addressed instead of making up new ones? Thanks. 😁

@craigmaloney I think there are a lot FOSS tools out there, that were never intended for "just use".

"Just use" is a concept that has a focus on users and user requests as the programmers behind that usually "write the software for the users" and therefore usually figure out a business model for it.

I think most FOSS projects are "feel free to use" projects, that share a piece of software that solved the problem the authors have/had. The user is not the focus here.

@sheogorath We passed "scratch the itch" a while ago when Scribus added PDF export for x1a and 3. Those have no other purpose other than professional printing. It's an excuse at this point.

@craigmaloney Feel free to correct me if I'm wrong as I'm not part of the community there.

When I see it correctly there is no commercial offering behind the software. There is no "Throw enough money at me and it'll be fixed tomorrow", I don't even see people working on that full-time.

Which again seems to be a funding problem. So I guess either someone steps up and offers some kind of commercial plan which could solve this, or it stays a "scratch my own itches"-kind of project.

@sheogorath I'm looking beyond trying to figure out what the root cause is. I just want it fixed so we can have more interesting conversations about Scribus and FOSS outside of "it's not ready for professional work and here's the receipts".

Telling me why it's not getting fixed is how we stay mired in the problem. Putting some will into getting it fixed is more productive.

@craigmaloney I guess the answer is: In order to get it fixed, send an email to the team members if they would like to offer paid support and how much it would cost to get this fixed ASAP?

In orst case the answer might be "No, no time" then you would extend the request to the rest of the community. If this doesn't work out, the answer is probably either fixing it yourself or hire a freelancer. Sorry when the solution is too boring 🤷

This seems like a chicken or the egg problem. Programs can never be ready for "production" unless they have been used extensively by demanding users in the industry. Why? Because a developer can't possibly find all of the problems users might encounter when using the software. The man from the blog post you mentioned seems to be very aware of that and is actually motivated to discover bugs and report them so that the developers are able to improve their software. Imo that's great!

@craigmaloney good luck forking projects to fix that problem though. 😅

I'm given to thinking the reason these issues never get fixed is because those inclined to do so experience a ridiculous level of pushback from a vocal minority and think "screw it, I'll just dual-boot Windows because that's less of a hassle"

@trechnex I don't want to fork it, I want to get it fixed. I'm tired of hand-waving this away. I think we can do better.

(And yes, I know your history with forking the other CMYK beast that starts with G and I can empathize with how much of a struggle getting something simple implemented can be)

@craigmaloney fun fact: That application doesn't actually support the CMYK colourspace.

A plugin called Separate looks promising though!

@craigmaloney I tend to think it's a lost cause. Let me explain.

Sometimes you just can't "figure it out" if the problem is in proprietary drivers or a closed service software. Like, try writing an FLOSS client for a proprietary service: it'll break eventually either because they don't care about API compat, or they'll break you because you don't play by their business rules.


@craigmaloney So the root of the problem is users who want to deal with proprietary software (because it's useful), which means that FLOSS tools will remain either less useful if they refuse to work with proprietary stuff, or broken.

There will be exceptions of course, but the trend is not happy.

@isagalaev The trend is going to keep us being an exception to any serious work flow.

This is the same issues we had with CUPS and printers (remember those days?) Somehow we managed to make that problem boring. I think we need to do the same here.

@craigmaloney @davidrevoy we did prints for a school litmag with that once,,, they declined to use it afterwards.

@craigmaloney Yes, Scribus can be/is a such a pain, specially color profiles and working with color in general (although color profiles and color printing is *ALWAYS* controversial). This project is pushing its limits in a way that I'd never dare to. OTOH I've managed to work flawlessly on several b/w projects, but the app is soooo slow when you want to edit text and all pages are displayed. I've developed some tricks to not be annoyed by things like that, and most of the time I just endure it.

@craigmaloney @davidrevoy the comments are starting to be pretty interesting though, along the line of "If you were wondering why Scribus is a better pick than commercial stuff just look how quickly free software heals itself." 🙂

@craigmaloney @davidrevoy The terrifying moral of the story that I take away is that, if something this fundamental to the concept is so broken, then it's very likely that nobody is actually using Scribus except as a test case, whether that's testing code or evaluating (and then discarding) the tool.
So, now there's a chicken-and-egg problem of the team not being able to fix things without good bug reports, but no bug reports because it's not worth using.

@jcolag @craigmaloney @davidrevoy

🍬It seems this is the subthread where I'd still have something original to say.

Commonly-used software improves faster in the FOSS world because there are enough real users to encounter all the "features". FOSS with a small target audience either needs to be written by Donald Knuth or never gets central bugs fixed if they're not part of the dev team's workflow when they switch to the user hat. 🍬

@craigmaloney @davidrevoy

While reading this thread you'll see the issue, (I am guilty of it too) you will see often that the discussion about creative tools in the foss forum often steers towards technical aspect and goes into the developer centric talk. This shows a lack of empathy and a lack of acceptance of the fact that now foss has people with other fields too.

If developers do want their software to be used by users then they need to include their users in the process.

@craigmaloney @davidrevoy , but i believe with more artists coming to FOSS this is slowly changing and projects are listening to them, even if the process is slow we do see improvements.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!