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

davidrevoy.com/article747/the-

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.

Show thread

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.

Show thread

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.

Show thread

@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

@craigmaloney

@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.

@brennen

Follow

@dredmorbius
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. 😁

Sign in to participate in the conversation
Mastodon @ UMU

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