Just paying Figma because nothing else works
fasterthanli.me
fasterthanli.me
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.
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.
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.
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.
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.
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.
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.
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.
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.
Looks like a nice product, but I would not consider it a FOSS alternative to GIMP.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It just worked. There was support. I wouldn't dig a hole in the ground with my bare hands, why wouldn't I use good tools. Of course I would like to use F/OSS for various reasons.
The model I absolutely love is Jetbrains, their core product is OSS, Apache licensed. The whole thing, totally usable. https://github.com/JetBrains/intellij-community
The money I send their way does both, it pays for developers and it puts an amazing artifact in the world that others can use and learn from. If they weren't open source, I wouldnt pay for it. I don't know how many others are the same as me, but Jetbrains really deserves credit here.
One reason I never could get into OmniGraffle: I can't just pass a file to a coworker to continue editing on their side, if they doesn't also pay for OmniGraffle. In contrast a plantUml/mermaid diagram will work, and they'll have the choice on how they want to edit it (albeit I don't think there is any good, non text based visual editors...)
A commercial player coming up with a very good plantUml/mermaid compatible visual editor would be a godsend (albeit, such a niche market I don't know if it would be profitable)
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.
> one of the best snapping systems ever created
Not the best though. That honour goes to IPE.
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.
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.
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
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.
- 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.
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".
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.
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'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.
Also, "what is taking so long for this page to load?".
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?
But it's a long article, so I guess I should have just reacted to the headline instead rather than reading the article.
This is Macromedia Flash erasure, which had all of the mechanics it seems Figma now has w/r/t paths.
The hard part is making a WYSIWYG editor, which both Figma and Penpot accomplish beautifully. The freedoms described in their marketing material may not be for you, but they are not indicative of poor quality.
Quality is an expression of priorities. I find this kind of rant frustrating because it's missing the forest for the trees.
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.
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.
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.
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.
I didn’t grow up in a religious environement, but both the mindset you grew up in, and your personality, could very well be me.
I’m stll very much struggling with this, btw.. I *KNOW* paying for software is good because time is more important than money, but I still don’t know where to draw the line..
Should I pay 30€ for ChatGpt? And Photoshop? And Netflix? And then what? The stuff adds up…
The only exception nowadays is subscriptions. I avoid those wherever I can, and will happily buy a more expensive/inferior alternative rather than pay a subscription. That might be irrational too, but I can't shake the feeling that I'm being ripped off and/or exploited any time I need to pay for a subscription.
“Just when I thought I was out, they pull me back in!” — Michael Corleone
You do know that Adobe acquired Figma?
Of all the text in the article, this is what I took issue with most.
Docker-compose is fine for running the vast majority of my stuff in production (combined with portainer).
Makes it tougher to grok for me ....
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.
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.
(from the section about Penpot)
Is there any particular reason? Maybe it depends on what "in production" means for you, but all my homelab stuff runs in Docker using Compose files and it's completely solid. Only me and some friends are using it (mostly Nextcloud), so I don't see a reason to scale horizontally ever.
There’s a ton of shapes, but they are all inconsistent visually that mixing metaphors becomes a real mess. Search is terrible. I often find myself spending more just screwing around trying to get things laid out how I want than actually designing.
Figma isn’t really designed for this kind of thing but I find that with FigJam I can throw together really great flowcharts and infrastructure diagrams with really little effort. UML state diagrams and other things of that ilk are too much effort though.
Ultimately I work at a Microsoft shop so whatever I do in Figma ultimately ends up in Visio anyway but I find it faster to prototype in Figma and then adapt to Visio. (As frustrating as it is.)
https://help.penpot.app/technical-guide/getting-started/#ins...
Didn't see any mentions here.
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.
What does work is to print the diagram to a PDF printer. This puts the diagram on a full A4 page so it's necessary to crop it afterwards. This can be done with some command line tool or other and automated using makefiles.
Why not yed? It's totally free (but not open source) and the only tool I've found (ever) to replace MS Visio.
https://www.yworks.com/products/yed
they even have an online version nowadays (but I've never used the online version) https://www.yworks.com/yed-live/
[1]: https://github.com/swyxio/spark-joy/blob/master/README.md#ge...
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.
Even Inkscape's native format is SVG which is primarily a screen/digital format.
[1]: https://penpot.app/
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.
If someone wants to argue "It just doesn't magically fall into my lap", there's no point in arguing. Ok, I'm sorry you don't understand computers. I'd also be frustrated I were you.
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.