Personally, I've found a lot of stuff that could be a figma or drawio (or inscape etc., yes) are more effective being a PUML or DOT or MetaPost file (or whatever format floats your boat) - not because it's easier to make (it isn't) but because it's much easier to change coherently and they change a lot. You can version control it better also.
If you want a prettier final form for some sort of final frozen version, redraw it in whatever tool you like.
I find mermaid is simple enough non tech people can use it, and has fairly broad support. PUML can obviously do more, but mermaid is there, which helps out tremendously
Could you give several examples of what is missing in Inkscape, but is implemented well in Figma? I only used Inkscape so I don't know much about Figma.
My experience with Inkscape is limited but last I used Illustrator, it felt very print-oriented and awkward at best for the use case of creating screen-destined vector graphics. That's actually what pushed me into starting to use Sketch for those purposes about a decade ago.
Perhaps open source would be better if we had less people like this willing to fund proprietary development while writing hate pieces towards open source.
Open source is amazing. It's more than good enough to stand people writing snarky hot takes to increase their blog viewership.
It just turns out that the economics of open source aren't necessarily a good fit for every use case. It's just not going to win everywhere for every user.
I'll give you an example: computer algebra and graphing.
Open source we have maxima (and wxmaxima). It is.... well weird but highly functional. It crashes from time to time but when it's not crashing you can do a lot with it. Every plot has thousands of options and you sort of need to specify most of them to get anything that looks half-decent. For some reason I don't fully understand you have to specify gnuplot options as well as maxima options sometimes but it's nice that it supports both of them. It's an absolute labour of love by the team who develop it.
Paid for there is Mathematica. If you're a student it's like 75 bucks a year but if you're trying to use it in industry it's nearly 4 grand. Per user per year. It can do basically the same sort of thing as maxima but the graphs look amazing out of the box, the options aren't weird, there is support etc etc.
Now here's the thing: Maxima is much better than Mathematica at certain things. And it's free. But it's really weird and some simple things are hard (like just graphing 2 2-d plots on the same axis) until you get the hang of it. And it's sort of lispy which I like but is weird for many people.
Open source is great, but why should anyone expect engineers to create serious alternatives to products with millions in revenue for them for free?
I'm probably kicking the hornets' nest here, but I see this as a naive perspective that mainly benefits big tech and VC-funded projects that can afford to fund free stuff as loss leaders or funnels into their proprietary offerings.
You should want to pay for the important tools you use. That's how you know that that they're sustainable, that fixes and improvements will be prioritized, and that there's no ulterior motive for the owner of the project. It also creates a healthy ecosystem where indie devs and startups can get traction and make money when they build useful stuff. A race to the bottom only benefits the established players.
what works even better is a quick sketch for your website/diagram uploaded to Chat GPT4-V, a description of what it is and a request output it in the code you want that makes it executable
but that's $20/month so maybe this person hates that
such as? all the teams I’ve been on have been using these tools to ultimately get them to be something more than pictures, what I described seems to skip that process and those personnel entirely
> what I described seems to skip that process and those personnel entirely
You’re not wrong; however in many orgs this behavior is highly discouraged to the point of being grounds for termination, and for good reason: you’re sidestepping the design process in order to build something which may or may not be correct, then you have to go back and fix it anyways to meet the spec which wasn’t clear yet because you started development without nailing down the design first.
I enjoyed the writing style. It's too long for me to read fully - I'm supposed to be working - the length and meandering adds to the charm perhaps. The person is clearly expressing themself.
I think we're living in a time where the tendency to see "smug" in writing/speaking/personalities is unusually high. There's a deep hatred for smugness that is maybe justified and maybe not, but regardless it has been wildly overapplied during the past 10 years.
Specifically I think the line between writing in a colloquial, sarcastic, dry, opinionated, florid, or satirical style; and being arrogant; is where we are overinterpreting things as the latter.
We seem to be sensitive to the idea that somebody might think they are "better than us". It seems often like an insecurity?
I think it's just that what you wrote is the difference between good writer and great writer.
> the line between writing in a colloquial, sarcastic, dry, opinionated, florid, or satirical style; and being arrogant;
If the point they're making is clear, the prose is informative, entertaining and never boring, being smug is a writing style like any other, people will like it. If the writing is annoying, people will criticize the smugness, when in reality that just means they didn't like it.
It's also possible that the success of sarcastic, satirical styles drew a lot of people to these styles, and not all of them are successful in using these styles.
Figma is the one product I will not stop preaching about, you literally have to stop me before I start singing it's praises. For me it's made redundant illustrator, acrobat, indesign, PowerPoint and miro. I'm almost free from adobe jail.
It's extremely meh. It's iOS-ified. There are no files, just some proprietary database of your drawings. You can only export to PDF. You can't import vectors. There are no dimensions inspectors where you can enter numbers, because that feels weird in iOS.
You will draw your thing by hand and you will be happy.
Nothing is wrong with deploying with docker-compose. Many people will push you toward k8s but if compose does the job there is absolutely no reason to introduce the complexity of k8s. Compose will get you far. (farther than many people think).
"""
What you're meant to do is, of course, run it on Kubernetes, which is largely the same (it's containers all the way down) except it's configured differently, you can now think about scaling out (on several nodes), you have actual health/liveness checks and policies for rolling out new versions, restarting, etc.
It's k8s! We all love to hate it, but at least the industry has sorta standardized around it, so that makes commiserating easier.
And because penpot is made up of three services (backend, exporter, frontend — not counting postgres and redis), although you could technically deploy all three of them separately, the idiomatic and era-appropriate thing to do at the time of this writing is to use a helm chart, which lets you deploy several resources at once.
"""
It's fine if you've got a low-volume service or one where downtime isn't a huge deal. If you ever find yourself needing e.g. autoscaling due to load or you start measuring how many 9's of uptime you get, then you'd want to look elsewhere.
Compose is fine for what it is, it’s served my personal VPS for years perfectly and I’ve hosted internal tools for teams with it for stuff that would never need to scale beyond that instance and never needed to be public. Personal projects and even small companies can likely get away with it just fine.
But if you’re dealing with any larger organization they probably don’t want to deal with you spinning up a random unprovisioned server running docker and compose services and will require stuff like Ansible scripts or similar to manage it. Once you start trying to manage docker-compose with extra tooling you might as well bite the bullet and learn k8s and get more out of your time and learning investment.
Yep it's funny to me how many developer/poweruser type people act like exchanging money for goods and services is a weird unsavoury concept. Do they have this same hangup in other areas of life?
I don't like having my personal workflows dependent on payments or subscription fees, and I don't like rewarding enshittifying corporations deliberately worsening free programs with feature restrictions and manipulative upsell ads (see Windows 10/11, Discord, scummy mobile apps/games, etc.) Re. other areas of life, I will pay (limited) amounts of money for scarce goods (which software isn't), but frankly it's terrifying that you're reliant on unaffordable payments and subscription fees to avoid freezing or starving to death in real life. Given my current (in)ability to hold a job, I don't see a long-term future for myself surviving.
technically yes. Esepcially as more and more things veer towards monthly subscriptions that have no business requiring a service. I will try to seek out cheaper or "free" solutions as more and more things try to leech money from me.
If something I need is a one time payment of $200 and is worth it, I'll grab it. If it's a $15/month subscription I'm put off, even if I may only use it 6 months and it comes out cheaper. I'm forgetful as is and I despise the thought of continually paying for something I've forgotten about. But I know I'm the odd one out there.
Odd to say after making a statement about two extremes.
But for me, it's more about stability. Jetrbains is great for me too but I don't feel so dependent on it with a project that it shitting the bed would endanger my own aspects. I can still use Visual Studio or Sublime Text or even go back to good ol' vim if needed. That flexibility of choice ironically enough makes me fine with paying for what's best for me.
But for me, take a game engine. That's a very core part of my project and lately we've see how the two biggest competitors can screw things over so easily. They may be the best choice, but are they MY best choice?
As things are now I'd rather choose a tool I'll struggle with more but have more control over. Because if a game engine suddenly wants to demand retroactive payment, that's a huge issue for me. And I don't mind spending some time helping out other engines rise up so others can make an easier jump.
I am wondering why he didn't at least try Inkscape. Since 1.0 it has gotten SO much better. It even has much better export quality compared to figma (from much more accurate gradients to strokes), and it has one of the best snapping systems ever created. He should seriously check it out!
I love Inkscape on Linux, and abuse it for desktop publishing and basic CAD work, but on Windows and Mac (especially Mac) it just doesn't seem to work as well and I don't understand why. I almost feel bad suggesting it to people because of this
> I needed to make diagram,s so I compared a few options and quickly settled on "draw.io"
So this not rules out that he didn't at some point. But still to my graphic designer eyes choosing either Inkscape (and even more, Figma) for doing simple diagrams is really, really weird.
* Disclaimer: I'm a heavy Inkscape user, it's been one of my main tools for all of uni and my professional work since 2006 - yes, it has some unpolished details here and there, but still it's great and (for me) miles better than any paid non-free tool
Yes, but what I am trying to say is that figma is not a diagramming tool. It wasn't built to create diagrams. Inkscape wasn't either, yet Inkscape still has some support for diagram creation, even if it is quite poor.
Inkscape and diagramming tools are trying to solve very distinct solutions.
Inkscape is a general purpose vector graphics program, designed to let you do anything.
Diagramming tools are there to provide you with a fast way to draw a diagram, which most importantly often contains connecting boxes with arrows that will auto-route and re-route when you move the boxes. I'm not aware of Inkscape supporting that, and I suspect that even if it somehow does, it'll require many more clicks.
Draw.io is good enough for a one-off usecase, but if you're creating a couple diagrams and consider your time to have monetary value, the better usability of Figma means it'll pay for itself really quickly.
Yes but figma wasn't made for diagrams either. Both are vector design tools, not diagramming tools, that's why I am asking: if figma was okay then why not Inkscape?
It's by no means a full replacement for the sorts of tools you'd get in Draw.io but it's not nothing.
It lets you create a two-node SVG path with a bit of extra metadata. One or both nodes connect to a special node at the centre of a shape.
Inkscape automatically makes that be a straight line trimmed to the edges of the shape(s. You can move the shapes and have the line move too. If you move the path itself it turns back into a regular path.
The path is just a straight line as mentioned and there's certainly no routing logic.
My point is: does figma have it? No! Figma has not a single option for diagram drawing; at least Inkscape is trying to. I am just confused about why he chose figma for this specific use case
My guess: it runs in the browser, and it's familiar / already invested in.
I may prefer something like excalidraw as a quick diagramming tool, but if you already have a hammer which is paid for, has SSO and access control set up, etc, many things take the shape of a nail.
Right, I forgot to mention that — I bought Affinity Designer 2, and I'm really with it, but diagramming in it is an absolute chore. Two completely separate usecases for me.
> it has one of the best snapping systems ever created
Is this documented somewhere? inkscape.org points to inkscape-manuals.readthedocs.io which doesn't cover it at all. I can't even get it to snap to an anchor if the grid is showing, and I can't get it to snap to the grid if the view isn't zoomed close enough.
Yet Inkscape's snapping system changes pased on where your cursor is, making fine tuned alignments much better than ANY other software. Yes, I know it is a complex system that's not very well documented, but my point still stands.
IPE is also a pretty good diagram editor, though it is quite heavily tied to LaTeX and more oriented towards maths / geometry diagrams than technical block diagrams. Draw.io is best for the latter, except for the stupid limitation that you can't really export text objects to real SVG as mentioned in the article. It just embeds HTML objects in the SVG which means they only work in browsers.
I know Inkscape is terrible for making diagrams, but what I am trying to say is that figma is even worse. Inkscape has at least some tools to help you create some diagrams, but figma is just for UI/UX design, not diagrams.
> Not the best though. That honour goes to IPE.
Never heard of IPE, I am going to check it out, thanks.
A reasonable article outlining why sometimes it's worth paying for software and going into detail about what exactly is wrong with the free alternatives.
But it's a long article, so I guess I should have just reacted to the headline instead rather than reading the article.
Does it support exporting to SVGs without requiring the used fonts installed on the viewer's system? That seems to be the issue the author is trying to address.
I only read the article once, but to me it seemed like this was an explicit requirement: produce a vector artifact that renders the same on all platforms without dependencies (basically a PDF?) and without invoking a browser in the build process.
Sort of like folks would praise Go's ability to compile a static binary without dylib dependencies besides libc.
Embedding fonts isn't really great for SVG exports; either you link to the fonts, in which case the SVGs only load correctly when the user has the font locally or is online, and the CDN is still running; or else you embed them as base 64, which makes the image very large.
We do the base 64 route for tldraw, which is sort of the best of all bad options. I'd like to someday add more export options so that a creator could host the fonts themselves on the same site where the SVG is shown.
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.
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.
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.
>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.
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.
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 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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
what about Excalidraw / TLDraw? there are so many of these canvas drawing apps[1]. draw on them, take a screenshot. doesnt export to svg but do people really need that?
Every time I use Figma, I say to myself, “so we are reinventing Dreamweaver” and that’s not necessarily a bad thing. It’s absolutely absurd that Adobe bought Macromedia/Dreamweaver and did nothing with it. I have no doubt they will do the same thing with Figma. Yay product innovation!
I've used Figma a lot in the last few years but I haven't used Dreamweaver in over a decade.
I've never thought to compare them as similar tools and I still can't really understand the comparison. Figma feels a lot closer to Illustrator than Dreamweaver to me.
Dreamweaver or Fireworks. I miss FW so much. It had that perfect blend of vector, bitmap, and text handling. Figma is the closest anything’s come to matching it.
Adobe could introduce a re-tooled Fireworks for teams and make a killing, but instead they went with XD, which failed to gain any traction, hence Figma.
That's enough of an endorsement I might give Figma another go.
I've delayed some macOS updates primarily because I don't want to leave FW behind, but it's getting to be well past time. Actually looking into acquiring a windows version / license so that I can run it virtualized on occasion. Wish there were something actively maintained that hit that same sweet spot.
They will need to do something with it, because they killed Adobe XD for it.
If they don't do anything with it, this will drive people (back) to tools like Linearity, Pixelmator and Sketch in droves which will kill Creative Cloud - and the company.
It hasn't been finalized yet, I link to a bloomberg piece in the article from 10 days ago that says it _looks_ like they're going to go back on it but nothing confirmed afaict.
I thought the DOJ was pretty stern on blocking this deal as it would be anticompetitive to users and would result in the outcome others have described here in the comments.
Every time I use Figma, I think... weird they would put a tool on the web and not use the web (especially when it is used so often to prototype designs for the web).
Also, "what is taking so long for this page to load?".
Exporting text as paths in SVG makes the text non-selectable and non-copyable. What SVG should have done, is to allow specifying both text and paths to draw the letters. This is one of multiple problems with SVG.
You can embed the font file into the SVG if you want the text to remain selectable. If the size increase worries you, you can strip unused glyphs from the font file before embedding it.
Yes, PDF is what I really want, but apparently it didn't get the "<img> tag treatment" so, we have to leave with "SVG with text as paths, and perfect layout" or "SVG with embedded fonts (a subset if you're brave), and selectable text".
I guess when you get people to pay for your product who REALLY REALLY don't want to, where every fiber of them screams, I DON'T WANT TO PAY, you got a winner on your hands. When a friend of mine spent $20 a month on a ChatGPT subscription, I couldn't believe it, he is very frugal with this stuff as well.
I hate spending money on software. I pirated Adobe Creative Suite for years. I really, really did not want to pay the $55/month for a Creative Cloud subscription, but I had to. There are no great alternatives to Photoshop + Premiere + After Effects. I have Affinity Photo, I have Da Vinci Resolve, and Fusion. But at the end of the day Adobe makes the best video production/animation software. I reluctantly bought a subscription and it's been worth it for me. I still hate Adobe's business practices but their software is still extremely well made.
I so often see people complaining about the price of Adobe tools saying it's over the top or greedy, but then they continue to pay and use it despite cheaper alternatives existing.
Consider that the reason their software is so much better than the rest is _because_ they charge this much and can reinvest it in to the software.
My company is also a Figma customer but for many diagramming stuff, more business oriented, I find Google Slides very handy for simple diagrams and good magnet connectors. In a distant the past I pivoted from Visio to Draw.io but always feel that draw.io seems like unfinished work after many years.
Instead of Draw.io or Figma (or Mermaid or any other option), I sketch around with Excalidraw and create diagrams with Miro. Miro took the world by the storm when corona hit and I am not super fond of the way people use it for everything from Kanban walls to whatever, but it does the diagram parts really well and works fast.
I bet I have wasted hundreds of hours fighting to get lines straight or arrows pointing to the correct direction with Draw.io - Miro they always just work.
Eng teams and PMs using Miro for retros and sprint planning is one of the stupidest tech trends I've seen in the last 2-3 years. Panning and zooming and manually sizing and moving post-it notes, we might as well do agile ceremonies in Tabletop Simulator.
For diagrams, Excalidraw (https://excalidraw.com) is my favorite by a lot. Pretty low learning curve and you can use it as a single-player as many times (you'll have to export the older file)
> I was also taught "it's a poor craftsman that blames their tools", which apparently means "take responsibility for your fuckups", but, to young-me, definitely sounded more like "you don't deserve nice things".
This may be controversial. I think this phrase is very misunderstood. As a former craftsman I think the real meaning was more to do with how a real craftsman only has good tools and maintains them properly. They can't blame their tools, because they are beyond reproach.
>while the good craftsman learns to use what they have
No, he goes out and gets new ones or fixes/builds them himself. That's how I always understood the saying; the emphasis is on the word "blame" not the word "tool". It's about people who sit around and complain rather than taking action to fix the problem. It doesn't mean you should put up with shitty tools.
Your interpretation appears to be unique. At quick search shows the common understanding to be about taking responsibility for your work and not blaming your tools. There's nothing about changing your tools:
His interpretation is similar to mine, higher up this thread. It is therefore far from unique.
I think it is also not at all unique for scholars to hear a saying and assume a meaning from it, and because they wrote it down on wiktionary it becomes the 'official version'. Whereas my version came from working with other tradesmen for a decade...non of whom were scholars, but were the owners of the culture.
some get better tools, some become experts at MS Paint and make you wonder how they do it. and everything in-between.
I always interpreted it as "a good craftman understands fundamentals". Photoshop can't save a bad artist. but a good artist can work without PS, even if it costs efficiency.
There's a huge difference in steel quality among chisels/cutting tools. Anyone can sharpen a $2 chisel so it cuts nicely once, but a $50 chisel will hold its edge longer and cut nicely hundreds of times.
There's only so much maintenance you can do on a bad tool.
239 comments
[ 2.4 ms ] story [ 302 ms ] threadPersonally, I've found a lot of stuff that could be a figma or drawio (or inscape etc., yes) are more effective being a PUML or DOT or MetaPost file (or whatever format floats your boat) - not because it's easier to make (it isn't) but because it's much easier to change coherently and they change a lot. You can version control it better also.
If you want a prettier final form for some sort of final frozen version, redraw it in whatever tool you like.
Even Inkscape's native format is SVG which is primarily a screen/digital format.
It just turns out that the economics of open source aren't necessarily a good fit for every use case. It's just not going to win everywhere for every user.
I'll give you an example: computer algebra and graphing.
Open source we have maxima (and wxmaxima). It is.... well weird but highly functional. It crashes from time to time but when it's not crashing you can do a lot with it. Every plot has thousands of options and you sort of need to specify most of them to get anything that looks half-decent. For some reason I don't fully understand you have to specify gnuplot options as well as maxima options sometimes but it's nice that it supports both of them. It's an absolute labour of love by the team who develop it.
Paid for there is Mathematica. If you're a student it's like 75 bucks a year but if you're trying to use it in industry it's nearly 4 grand. Per user per year. It can do basically the same sort of thing as maxima but the graphs look amazing out of the box, the options aren't weird, there is support etc etc.
Now here's the thing: Maxima is much better than Mathematica at certain things. And it's free. But it's really weird and some simple things are hard (like just graphing 2 2-d plots on the same axis) until you get the hang of it. And it's sort of lispy which I like but is weird for many people.
I'm probably kicking the hornets' nest here, but I see this as a naive perspective that mainly benefits big tech and VC-funded projects that can afford to fund free stuff as loss leaders or funnels into their proprietary offerings.
You should want to pay for the important tools you use. That's how you know that that they're sustainable, that fixes and improvements will be prioritized, and that there's no ulterior motive for the owner of the project. It also creates a healthy ecosystem where indie devs and startups can get traction and make money when they build useful stuff. A race to the bottom only benefits the established players.
but that's $20/month so maybe this person hates that
You’re not wrong; however in many orgs this behavior is highly discouraged to the point of being grounds for termination, and for good reason: you’re sidestepping the design process in order to build something which may or may not be correct, then you have to go back and fix it anyways to meet the spec which wasn’t clear yet because you started development without nailing down the design first.
Specifically I think the line between writing in a colloquial, sarcastic, dry, opinionated, florid, or satirical style; and being arrogant; is where we are overinterpreting things as the latter.
We seem to be sensitive to the idea that somebody might think they are "better than us". It seems often like an insecurity?
> the line between writing in a colloquial, sarcastic, dry, opinionated, florid, or satirical style; and being arrogant;
If the point they're making is clear, the prose is informative, entertaining and never boring, being smug is a writing style like any other, people will like it. If the writing is annoying, people will criticize the smugness, when in reality that just means they didn't like it.
It's also possible that the success of sarcastic, satirical styles drew a lot of people to these styles, and not all of them are successful in using these styles.
Take responsibility for your opinions, don't make your reader sift through vague intentions.
“Just when I thought I was out, they pull me back in!” — Michael Corleone
You do know that Adobe acquired Figma?
But, no, instead they'll do something involving 3d emojis or something similarly useful.
You will draw your thing by hand and you will be happy.
This might be a stupid question: what is wrong about deploying with Compose? What are the "proper" ways of doing things?
""" What you're meant to do is, of course, run it on Kubernetes, which is largely the same (it's containers all the way down) except it's configured differently, you can now think about scaling out (on several nodes), you have actual health/liveness checks and policies for rolling out new versions, restarting, etc.
It's k8s! We all love to hate it, but at least the industry has sorta standardized around it, so that makes commiserating easier.
And because penpot is made up of three services (backend, exporter, frontend — not counting postgres and redis), although you could technically deploy all three of them separately, the idiomatic and era-appropriate thing to do at the time of this writing is to use a helm chart, which lets you deploy several resources at once. """
But if you’re dealing with any larger organization they probably don’t want to deal with you spinning up a random unprovisioned server running docker and compose services and will require stuff like Ansible scripts or similar to manage it. Once you start trying to manage docker-compose with extra tooling you might as well bite the bullet and learn k8s and get more out of your time and learning investment.
Then there are people who want to live their best life.
If there is something I need that provides value then my wallet instantly comes out.
I more than happily pay for my JetBrains IDE - it's a tool I use full time.
Same for ChatGPT - I'd throw my money at them. I'd pay 5 times as much.
I was paying for an anti spam system but I'm not convinced it was doing a great job.
A real world thing that’s similar is cordless power tools. All the god-damn incompatible battery styles.
If something I need is a one time payment of $200 and is worth it, I'll grab it. If it's a $15/month subscription I'm put off, even if I may only use it 6 months and it comes out cheaper. I'm forgetful as is and I despise the thought of continually paying for something I've forgotten about. But I know I'm the odd one out there.
Odd to say after making a statement about two extremes.
But for me, it's more about stability. Jetrbains is great for me too but I don't feel so dependent on it with a project that it shitting the bed would endanger my own aspects. I can still use Visual Studio or Sublime Text or even go back to good ol' vim if needed. That flexibility of choice ironically enough makes me fine with paying for what's best for me.
But for me, take a game engine. That's a very core part of my project and lately we've see how the two biggest competitors can screw things over so easily. They may be the best choice, but are they MY best choice?
As things are now I'd rather choose a tool I'll struggle with more but have more control over. Because if a game engine suddenly wants to demand retroactive payment, that's a huge issue for me. And I don't mind spending some time helping out other engines rise up so others can make an easier jump.
So this not rules out that he didn't at some point. But still to my graphic designer eyes choosing either Inkscape (and even more, Figma) for doing simple diagrams is really, really weird.
* Disclaimer: I'm a heavy Inkscape user, it's been one of my main tools for all of uni and my professional work since 2006 - yes, it has some unpolished details here and there, but still it's great and (for me) miles better than any paid non-free tool
Inkscape is a general purpose vector graphics program, designed to let you do anything.
Diagramming tools are there to provide you with a fast way to draw a diagram, which most importantly often contains connecting boxes with arrows that will auto-route and re-route when you move the boxes. I'm not aware of Inkscape supporting that, and I suspect that even if it somehow does, it'll require many more clicks.
Draw.io is good enough for a one-off usecase, but if you're creating a couple diagrams and consider your time to have monetary value, the better usability of Figma means it'll pay for itself really quickly.
Last time I checked (yesterday), I could not find that. Am I missing anything?
It's by no means a full replacement for the sorts of tools you'd get in Draw.io but it's not nothing.
It lets you create a two-node SVG path with a bit of extra metadata. One or both nodes connect to a special node at the centre of a shape.
Inkscape automatically makes that be a straight line trimmed to the edges of the shape(s. You can move the shapes and have the line move too. If you move the path itself it turns back into a regular path.
The path is just a straight line as mentioned and there's certainly no routing logic.
I may prefer something like excalidraw as a quick diagramming tool, but if you already have a hammer which is paid for, has SSO and access control set up, etc, many things take the shape of a nail.
Is this documented somewhere? inkscape.org points to inkscape-manuals.readthedocs.io which doesn't cover it at all. I can't even get it to snap to an anchor if the grid is showing, and I can't get it to snap to the grid if the view isn't zoomed close enough.
> one of the best snapping systems ever created
Not the best though. That honour goes to IPE.
https://ipe.otfried.org/
IPE is also a pretty good diagram editor, though it is quite heavily tied to LaTeX and more oriented towards maths / geometry diagrams than technical block diagrams. Draw.io is best for the latter, except for the stupid limitation that you can't really export text objects to real SVG as mentioned in the article. It just embeds HTML objects in the SVG which means they only work in browsers.
> Not the best though. That honour goes to IPE.
Never heard of IPE, I am going to check it out, thanks.
But it's a long article, so I guess I should have just reacted to the headline instead rather than reading the article.
Sort of like folks would praise Go's ability to compile a static binary without dylib dependencies besides libc.
We do the base 64 route for tldraw, which is sort of the best of all bad options. I'd like to someday add more export options so that a creator could host the fonts themselves on the same site where the SVG is shown.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
Looks like a nice product, but I would not consider it a FOSS alternative to GIMP.
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.
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.
> 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...
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.
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.
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.
I suppose there's Blender, but it's kind of a special case.
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.
Agreed on the handover cost, though (obviously).
Not saying that 5 devs are required, but 1 is not always the nicest IMO.
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.
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.
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.
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.
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.
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.
That’s literally what they’re doing, with proprietary software.
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.
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.
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.
vs
$FOSS_Project description: reproduces functionality of applicationX
how many people will be attracted to the first option vs the second?
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.
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.
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).
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.
These are two separate skillsets that often don't overlap, you won't find many UX people contributing to open source projects.
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.
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.
[1]: https://github.com/swyxio/spark-joy/blob/master/README.md#ge...
I've never thought to compare them as similar tools and I still can't really understand the comparison. Figma feels a lot closer to Illustrator than Dreamweaver to me.
I've delayed some macOS updates primarily because I don't want to leave FW behind, but it's getting to be well past time. Actually looking into acquiring a windows version / license so that I can run it virtualized on occasion. Wish there were something actively maintained that hit that same sweet spot.
If they don't do anything with it, this will drive people (back) to tools like Linearity, Pixelmator and Sketch in droves which will kill Creative Cloud - and the company.
Believe me that they will not do that.
No?
Also, "what is taking so long for this page to load?".
Makes it tougher to grok for me ....
Consider that the reason their software is so much better than the rest is _because_ they charge this much and can reinvest it in to the software.
LOL!!
I bet I have wasted hundreds of hours fighting to get lines straight or arrows pointing to the correct direction with Draw.io - Miro they always just work.
[1]: https://penpot.app/
This may be controversial. I think this phrase is very misunderstood. As a former craftsman I think the real meaning was more to do with how a real craftsman only has good tools and maintains them properly. They can't blame their tools, because they are beyond reproach.
I've seen amazing work come from very simple/inexpensive tools, or even inappropriate tools, and crappy work come from very good tools.
The poor craftsman says "my works sucks because the tools suck", while the good craftsman learns to use what they have.
No, he goes out and gets new ones or fixes/builds them himself. That's how I always understood the saying; the emphasis is on the word "blame" not the word "tool". It's about people who sit around and complain rather than taking action to fix the problem. It doesn't mean you should put up with shitty tools.
The other adage that goes in concert with craftspeople shouldn't be blaming their tools is that, "true artists work within the limits of the medium".
- https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h... - https://poemanalysis.com/proverb/a-bad-workman-blames-his-to... - https://idioms.thefreedictionary.com/a+poor+craftsman+blames... - https://usdictionary.com/idioms/a-bad-workman-blames-his-too... - https://writingexplained.org/idiom-dictionary/a-bad-workman-...
His interpretation is similar to mine, higher up this thread. It is therefore far from unique.
I think it is also not at all unique for scholars to hear a saying and assume a meaning from it, and because they wrote it down on wiktionary it becomes the 'official version'. Whereas my version came from working with other tradesmen for a decade...non of whom were scholars, but were the owners of the culture.
I always interpreted it as "a good craftman understands fundamentals". Photoshop can't save a bad artist. but a good artist can work without PS, even if it costs efficiency.
can doesn't mean they will, though.
Relating back to software as tools, this only works if you have access to the tool code.
There's a huge difference in steel quality among chisels/cutting tools. Anyone can sharpen a $2 chisel so it cuts nicely once, but a $50 chisel will hold its edge longer and cut nicely hundreds of times.
There's only so much maintenance you can do on a bad tool.
This is Macromedia Flash erasure, which had all of the mechanics it seems Figma now has w/r/t paths.