Okay it's open source but self-hosting it is not straightforward.
The repo's self-hosting doc link returns a 404. Then after manually finding https://docs.plane.so/self-hosting/self-hosting, I am warned that there is a dizzying array of 4 env files.
I suppose they are in a tricky situation, in that while they want to stand out as open source, actually having people easily self-host it, is perhaps, not a goal that is currently in their interest!
Correction: removed wrong Docker-Compose command interpretation, as I have been schooled!
Spent 10 minutes trying to get it running locally, couldn't.
They suddenly mention nginx in the self hosting docs - why?!
I don't understand open source projects that required you to fiddle around with scripts, environment files, reverse proxies etc to try the platform out! docker compose up should "just work" ™.
To be fair, 'try the platform out' to me includes getting an understanding of dependencies and configuration. Docker is useful for a lot of things, but even if I want to use containerization in prod, I'd prefer to build my own containers rather than being dependent on someone else's runtime environment, so getting hands-on with the setup is important to me.
If the goal is just to test the application functionality, a demo site that's already set up and publicly accessible would be much easier than having to deploy a Docker container.
In terms of Nginx, using it to handle web server functionality, and especially encryption, while acting as a gateway into your containerized apps is a pretty bog-standard approach, and makes for good separation of concerns. I don't see much value in having that stuff implemented separately within each application and creating more config complexity for sysadmin work.
Since they have a /pricing page it would seem their business is not to make it easy to self-host but in fact to make people pay for the cloud version instead.
If you just follow the documentation [1], it "just works". I just installed it on my machine, everything was up and running within 3-5 minutes.
They even wrote a setup script that saves you from the mind-boggling complexity of docker, giving you a simple menu where you only have to read the items and press a key. If you don't know which key to press, the readme [1] is very helpful. The only place where you will have to "fiddle" with the environment files is to change the default port from 80 to another. And if you're not ready for that, or not skilled enough to understand what that means and why you might need to do it - you're not ready for self-hosting and should take a step back and learn the basics of OS administration.
Oh, and they mention nginx because this software uses nginx inside a container. Hope that answers your question.
well some people like docker and some don't. If you are in the self-hosting realm, personally I think it is fair that the people doing it knows about DevOp or systemadmin, or else pay someone to host it for you.
I want to know what configs are needed to get things stood up. I actually don't dockerize things right away. I setup my nginx to forward to different machines in my network. When I settle on a home for things, I may (finally) get around to whipping up a Dockerfile.
Not everything needs to be enterprise whizbang out the gate.
Software installation, even for simple trials reminds me of this Stephen Hawking quote:
"Someone told me that each equation I included in the book would halve the sales. I therefore resolved not to have any equations at all. In the end, however, I did put in one equation, Einstein's famous equation, E = mc squared. I hope that this will not scare off half of my potential readers."
It just feels like that law can be adapted to: for every step and pre-requisite in your setup, you lose half your potential customers.
Of course, it's not precisely that, but it feels the same.
I, for one, am not afraid of manually building a stack to self-host an application. I'd prefer it over Docker in fact, because it makes everything exposed, and as an admin, I love to know what I'm tinkering with.
However, the docs should be good. No hidden layers, no skimped over steps, no "insert some magic here". It's your app, you know it by heart, but I'm just getting to know it.
If you do this as an established application or a developer which also sell your product as a SaaS, I assume that you're doing it in bad faith, and move on.
It's been a long time since I fell for the marketing slogan about a product like this being open source. I wasted a lot of hours learning that lesson. If a company has a financial incentive for something to not work, it's not that hard to make sure it doesn't.
I haven't look at this particular project, but having to type the same information into multiple env files is unfortunately pretty unavoidable. Making a Docker / Django project instantiable via template and then runnable locally and deployable in production unfortunately involves 5+ different variable templating systems, which each require their variables to be declared in different files and formats.
The Plane codebase is a good read. If you want to see a well put together Django + Nextjs project you should check it out. There has been a lot of talk recently about what open source means. To completely side-step that discussion, I have plane starred on github because I learned a lot looking at their code without ever having run it or ever using the product.
I can't speak for the Python part (which another commentator also already did comment on), but I don't think the React part is anything to highlight as "code you should try to imitate".
I just did a quick look, but it seems to suffer from common problems lots of UIs suffer from. Zero tests (unless I missed where they are located), even for things that doesn't even touch the DOM (like the "helpers"). Components filled with heavy logic at instead of being cleanly separated out. Just two examples after a quick 5 minute browse.
That said, I've definitely seen worse codebases and this wouldn't be too hard to work on in a professional setting. Clearly it works for them, and they seem to be progressing, which is good enough. But again, wouldn't flag it as "exceptional" either which you seemed to have done here.
IMHO UI tests are just too difficult to be worth bothering with in most situations.
Maybe AI will change that. But for now I think dev time is generally better invested in other ways of making code work properly, or just fixing bugs that have already been reported.
You are wrong. Just checked Django part. No annotations, `__all__` in serializers, exists+get instead just calling .first(), etc. It's no way a good Django codebase.
Also noticing copious use of select distinct within the views, which indicates issues with the schema. It may also partially be due to the somewhat limiting API provided by Django Rest Framework, which I personally tend to avoid. All things can be improved though.
It might not be perfect, or live up to whatever expectations you personally possess, but it legitimately is a pretty good example of a clean and straightforward Django application.
Although the structure is fairly good, but I'm always puzzled why testing is so neglected, especially with projects that are popular and - hypothetically - production-ready...
I suppose this mimics real software I've worked on in the past (though thankfully no longer). It seems most of the lessons of software development have fallen on deaf ears despite decades of preaching best practices to each other.
It's all fair criticism. The lessons learned will only take you so far, so the caveat is that if you think it's a bad project then you're already above a certain level. Go you :)
You might take it in the context that they are shipping a real product at a fair speed so where it deviates from ideal what you're seeing is the educated choices of the tradeoffs to make in a real business (which is a statement of the plane team's opinion, yours may vary).
Yes, this! People tend to forget when reviewing code long after it was written, that there is a lot of context around code that isn't "codified".
I remember looking once at a project me and some others got pulled into, where everything was working but the code was spaghetti (which, to be fair, is usually why I get pulled in), and they were having a hard time adding new features without breaking existing ones.
At first, our reaction was the same as many programmers; "Oh my god what have they done and why have they done it like this?!"
Turns out, the company was on the brink of extinction, had about two months of runway left and made this Hail Mary project to attract some new attention and eventually landed them new funding.
So the project was rushed, a lot, but that's OK, but if they didn't rush and wrote super shitty code, the company wouldn't have existed at all. They were OK with this, because they traded "existing today" for "refactoring in the future", which sometimes is the right call to do.
It’s funny as I think discord is actually kind of harder to get into than the old irc method. With irc there was no history or permanence so there was a relationship between discussion and what made it into the project as source or docs.
With discord it’s weird because the expectation seems to be on me to wade through hundreds or thousands of messages to find docs because there are people who hang out and read everything.
Discord does have an okayish search feature which gave me a desired answer most of the time I joined a server because of a particular program I had. Enormous downside being that you have to guess the previously used wording if you don't have an error message or something.
i was burned badly by mattermost when their expert functionality didn't work for months and eventually i missed the archival deadline and lost all of the history for a project.
Its amazing to me that it has become such a default, similarly to Slack before it. At least some Slack communities tried and worked on getting the channels indexed so that it shows up during web searches, now with discord I need an account just to view the content...
A hard pass from me, especially when an answer to a simple question requires me to drink from their firehose of a search...
I always go with discord in newer projects. Why? I feel like most people have discord nowadays and it just works (TM). I rarely have a case where a person said that they can’t join because they don’t have discord or don’t want to create an account because other reasons.
Beside that, money is also a big factor. Slack for example is getting more expensive for communities.
Slack doesn't require phone number validation, Discord does. Try to login first time with FF on Linux and with uBlock Origin defaults and then pooof, insta ban! Guess what, your phone number is banned for validation too forever,
This is weird. It’s almost as if this is a sales pitch to non-technical management who gets to make the executive decision on what issue tracker to use.
That’s almost antithetical to “by engineers, for engineers”
If this project is driven by commercial interests, then the open-source spirit, if any, isn’t genuine and won’t stick around once VCs want the bait-and-switch.
Edit: the blog post goes at length to discuss growth hacking and “engagement”. The reason Jira is the mess it is is because they tried to accommodate the feature request of every paying customer
Edit 3: it’s possible this engagement story is to impress VC / funding first, paying customers second
Edit 4: I’m starting to see the other commentary about plagiarizing Linear in a different light, now that I’m cynical about the ethics and honesty of this project. All the non trivial contributors are exclusively from a country known for Infosys, clickfarms for social media engagement, gamifying the interview/recruitment funnel (see Grace Hopper convention). If this was a truly global crowd source effort as the GitHub stars would make you believe, you’d expect to see more geographical diversity. There’s a point where GitHub stars isn’t just a weak signal, but a negative one
> All the non trivial contributors are exclusively from a country known for Infosys, clickfarms for social media engagement, gamifying the interview/recruitment funnel (see Grace Hopper convention)
I see your other points are valid but this was uncalled for.
The person who commented the telemetry issue (Kailash Nadh) is also from India and CTO of largest stock broker, he is also known for encouraging open source software.
A large amount of contributors to GSoC and LFX programs are Indian college students.
All the dysfunctions you mention are symptoms of large population - of which I too have been a victim of. But I have seen some very good engineers in this country too.
> All the dysfunctions you mention are symptoms of large population - of which I too have been a victim of. But I have seen some very good engineers in this country too.
Me too.
One of the best Indian candidates I interviewed was the one who had the worst college grades... probably because they focused on internalizing the material and actual problem solving. The other candidates all studied Leetcode, and was dumbfounded when asked a simple, non Leetcode question. The question was to bruteforce and guest a password to a website. I provide them the API definition to Login with a Username and Password. All they had to do was generate every possible password between 8 and 20 characters. There is no rate limiting and we don't care about optimality or runtime. The only tricky bit is that there are a variety of business/password words such as password strings can't start with a number. If they call the API with 5 passwords that don't satisfy the password rules, they get locked out. This isn't worded as a Leetcode problem, but it's really just generating every permutation and filter out strings that don't match some condition checks (which I enumerate for them. It's not a blackbox). Asking people to program against this API: boolean login(username: String, password: String) was enough to trip up these people with Masters degree.
The problem with people cheating the system is that it harms candidates like this.
What do you prefer? A software whose UI and workflow are good for upper management but a PITA for engineers, or a software "by engineers, for engineers" which has some sales pitch/material that can be appealing to upper management, who ultimately makes the decision to shell out the money?
37signals and BaseCamp built products that works for their own processes based on their experience as a software team. They productized it and sold it. I’m not contesting that the product couldn’t be sold.
The issue here is bring driven by growth engagement, giving this impression that it’s about listening to the community. My cynism is that that they don’t care about what makes most sense for the product, but what drives engagement. You can argue what drives engagement is best for the users. That idea is good in theory, but in practice trying to satisfy everyone’s need you will end up not serving any use case well. Go, atleast Go 1, make explicit trade offs that made many people dislike it, but it kept the language simple and excelled at its intended use case.
At any rate, I am cynical that the project here is driven by developer interest as much as it is about impressing VCs.
The problem isn’t that stars are imperfect, but they have become gamified. The emphasis on GitHub stars as a form of authority makes me trust this project even less. You’d expect VCs to do due diligence on the authenticity and quality of GitHub reviews, but I’m dubious about that, whether they are doing so out of willful ignorance or not is a separate question.
All of the contributors on this project are from the country that feeds to Infosys. I’ve seen enough inflated resumes from candidates who couldn’t write a loop despite having a masters degree. Ironically, the one candidate from this country I gave raving recommendations for was the one who had bad school grades. This country is also a hotbed for clickfarms and selling fake social media engagement/reviews.
It's not so much "not JIRA", it's that managing code bases outside of the code base is hard and awkward. And due respect to fossil-scm, I don't know if any way to do it otherwise.
The goal here is to look at something that tells an organisation why chnages to a codebase occurred. Each individual commit can have a nice explanation (in a given human language) of why that specific change occurred. But how does one link other commits, dozens or hundreds or orders of magnitude more.
Can they be accounted for to investors, auditors, regulators?
But equally demanding that commits link to something that links to why, it demands that the rest of the business also link to that something (ie JIRA) so they can explain why they expended time and effort
JIRA or whatever ticketing system, will slowly become the central repository of justification for expense - a great position sure, but also dangerous.
Following on, having some repository of why - of cost drivers - forces not just the software developers but the whole business to justify its activity against the repository. This seems hugely similar to lawyers billing by the 15 minute increment, and indeed a git repo will provide good billing like data too !
But the issue still exists - if I say my activity links to ticket number 1234, then we have a hierarchy (?) of what 1234 links to. The smacks of stories and epics and the whole agile package, but is also a common accounting process
my issue is that this is a neat, backwards looking explanation for what was done. It's not a good way to manage forwards.
And often I find the problem is people wanting to use JIRAs tickets to manage what will be done, not account for what has been done
Why the need to reinvent the commit message? Look at how Linux does it. If it's good enough for a globally distributed organization creating the operating system the cloud and most phones run on, it can't be completely wrong. They rely solely on mail and commit messages.
Ticketing systems are useful for a lot of other things such as keeping track of work on an individual level, or managing project resource allocations on a company wide level, but I'm not sure it's the best tool to do audits and have accountability. It will at best be a secondary source of that data.
And the Linux mailing lists are a great example of what I mean - deciding what to do and why is a huge upfront discussion - one they do in the open. but it's a crap backwards looking method for a summary.
Most businesses hide the upfront discussion (or at least keep it to a smaller set of people who have often conflicting incentives for decisions as well (we tend to refer to this as politics but that's a bit like fish moaning about water.)
Anyway the point is that Linux shows how to make good decisions in the open (usually) - a process that I think most would 10x good decision making in most businesses but also lead to huge other sets of problems (worth it in my view but ...).
But Linux does not have a simple way of post-hoc justifying the decisions unless one reads the threads (which is where the recent post of open source journalist at lwn was a great idea)
But things like Jira, external ticket stores are good at providing a hierarchy to post hoc justify the decision - even if they are a terrible way to plan forwards.
So the ideal I guess is some kind of open architecture discussion upfront and some kind of extract and rebuild the rationale from commits (ie in house journalism?)
I click the star on GitHub when I come across a project that doesn't seem immediately worthwhile, but that I might want to check back on in a few years.
I can't imagine caring about how many stars / likes something has.
Not copying existing ideas is the strangest thing to me. What is the point of spending months trying to come up with an original design, instead of just taking a proven design and improving on it / customizing it to your companies virtues?
In the fintech space I've seen so many startups hire designers to come up with original new designs and user experiences, only to arrive at the exact same design as existing fintech apps.
What is the point of refusing to stand on the shoulders of giants? Pride?
It's not black and white, but cloning a product is just not nice. The legality is probably fine, there might be an argument for copyright infringements, but unlikely to get any result.
Imo it's also good to realize in this kind of software, patterns and UI are very core to the product, so you are copying the essence of what this company has spend tons of time and resources to develop. Fintech might be different as it's less about UI.
Then there is also a difference between UI patterns and branding. The first: It's good to follow standards and expectations, the second should just not be copied imo.
Another factor is asking money for it, which it looks like they intent to do. I think that makes it even weirder to clone an existing product as now you try to compete and profit from other peoples work.
There is a fine but clear line between inspiration and copying, and imo this crosses the line.
Even if legal I would not use this product for that reason, and imo it reflects poorly on the people doing it.
Amen. This is somewhat reductive, but you need to identify the problem your users are trying to solve, look for similar examples in the wild, and commit to one you like. Avoid reinventing the wheel to satisfy your ego unless the product truly requires it.
Well, I believe everyone is following on the Tailwind Template UI designs with Neumorphic-ish patterns these days. For instance, check these templates and tell me you haven't stumbled on new Startups launches these days with strikingly similar designs.
Personally, I'm perfectly fine as long as they are pleasing to look and nice to use.
I don't know about IP, but Linear is a web app and company that is not broadly open source, not even open-core, and is not something presented as something the user can self host.
Readit News
https://docs.docker.com/compose/reference/
They suddenly mention nginx in the self hosting docs - why?!
I don't understand open source projects that required you to fiddle around with scripts, environment files, reverse proxies etc to try the platform out! docker compose up should "just work" ™.
Your Plane instance isn't ready yet Ask your Instance Admin to complete set-up first.
With nothing in the docs about this.
If the goal is just to test the application functionality, a demo site that's already set up and publicly accessible would be much easier than having to deploy a Docker container.
In terms of Nginx, using it to handle web server functionality, and especially encryption, while acting as a gateway into your containerized apps is a pretty bog-standard approach, and makes for good separation of concerns. I don't see much value in having that stuff implemented separately within each application and creating more config complexity for sysadmin work.
They even wrote a setup script that saves you from the mind-boggling complexity of docker, giving you a simple menu where you only have to read the items and press a key. If you don't know which key to press, the readme [1] is very helpful. The only place where you will have to "fiddle" with the environment files is to change the default port from 80 to another. And if you're not ready for that, or not skilled enough to understand what that means and why you might need to do it - you're not ready for self-hosting and should take a step back and learn the basics of OS administration.
Oh, and they mention nginx because this software uses nginx inside a container. Hope that answers your question.
[1] https://docs.plane.so/self-hosting/docker-compose
Not everything needs to be enterprise whizbang out the gate.
"Someone told me that each equation I included in the book would halve the sales. I therefore resolved not to have any equations at all. In the end, however, I did put in one equation, Einstein's famous equation, E = mc squared. I hope that this will not scare off half of my potential readers."
It just feels like that law can be adapted to: for every step and pre-requisite in your setup, you lose half your potential customers.
Of course, it's not precisely that, but it feels the same.
However, the docs should be good. No hidden layers, no skimped over steps, no "insert some magic here". It's your app, you know it by heart, but I'm just getting to know it.
If you do this as an established application or a developer which also sell your product as a SaaS, I assume that you're doing it in bad faith, and move on.
My preferred self hosted projects only need one container and has a embedded sqlite database. With the option to configure a external database.
Newer versions of Docker have Compose available as a CLI plugin, so the command `docker compose` with space is correct.
A simple bash template via envsubst?
https://docs.docker.com/engine/reference/commandline/compose...
Deleted Comment
I just did a quick look, but it seems to suffer from common problems lots of UIs suffer from. Zero tests (unless I missed where they are located), even for things that doesn't even touch the DOM (like the "helpers"). Components filled with heavy logic at instead of being cleanly separated out. Just two examples after a quick 5 minute browse.
That said, I've definitely seen worse codebases and this wouldn't be too hard to work on in a professional setting. Clearly it works for them, and they seem to be progressing, which is good enough. But again, wouldn't flag it as "exceptional" either which you seemed to have done here.
Maybe AI will change that. But for now I think dev time is generally better invested in other ways of making code work properly, or just fixing bugs that have already been reported.
I know that sounds heretical.
I remember looking once at a project me and some others got pulled into, where everything was working but the code was spaghetti (which, to be fair, is usually why I get pulled in), and they were having a hard time adding new features without breaking existing ones.
At first, our reaction was the same as many programmers; "Oh my god what have they done and why have they done it like this?!"
Turns out, the company was on the brink of extinction, had about two months of runway left and made this Hail Mary project to attract some new attention and eventually landed them new funding.
So the project was rushed, a lot, but that's OK, but if they didn't rush and wrote super shitty code, the company wouldn't have existed at all. They were OK with this, because they traded "existing today" for "refactoring in the future", which sometimes is the right call to do.
oh okay
> Join our Discord
sadness. where's the forum?
With discord it’s weird because the expectation seems to be on me to wade through hundreds or thousands of messages to find docs because there are people who hang out and read everything.
But J, they don't want to waste their time with hosting a messaging platform!
Well if that's the case, then why would others waste their time hosting their own project management board?
A hard pass from me, especially when an answer to a simple question requires me to drink from their firehose of a search...
Beside that, money is also a big factor. Slack for example is getting more expensive for communities.
This is weird. It’s almost as if this is a sales pitch to non-technical management who gets to make the executive decision on what issue tracker to use.
That’s almost antithetical to “by engineers, for engineers”
If this project is driven by commercial interests, then the open-source spirit, if any, isn’t genuine and won’t stick around once VCs want the bait-and-switch.
Edit: the blog post goes at length to discuss growth hacking and “engagement”. The reason Jira is the mess it is is because they tried to accommodate the feature request of every paying customer
Edit 2: seems they are logging telemetry by default https://github.com/makeplane/plane/issues/1694
Edit 3: it’s possible this engagement story is to impress VC / funding first, paying customers second
Edit 4: I’m starting to see the other commentary about plagiarizing Linear in a different light, now that I’m cynical about the ethics and honesty of this project. All the non trivial contributors are exclusively from a country known for Infosys, clickfarms for social media engagement, gamifying the interview/recruitment funnel (see Grace Hopper convention). If this was a truly global crowd source effort as the GitHub stars would make you believe, you’d expect to see more geographical diversity. There’s a point where GitHub stars isn’t just a weak signal, but a negative one
I see your other points are valid but this was uncalled for.
The person who commented the telemetry issue (Kailash Nadh) is also from India and CTO of largest stock broker, he is also known for encouraging open source software.
A large amount of contributors to GSoC and LFX programs are Indian college students.
All the dysfunctions you mention are symptoms of large population - of which I too have been a victim of. But I have seen some very good engineers in this country too.
Me too.
One of the best Indian candidates I interviewed was the one who had the worst college grades... probably because they focused on internalizing the material and actual problem solving. The other candidates all studied Leetcode, and was dumbfounded when asked a simple, non Leetcode question. The question was to bruteforce and guest a password to a website. I provide them the API definition to Login with a Username and Password. All they had to do was generate every possible password between 8 and 20 characters. There is no rate limiting and we don't care about optimality or runtime. The only tricky bit is that there are a variety of business/password words such as password strings can't start with a number. If they call the API with 5 passwords that don't satisfy the password rules, they get locked out. This isn't worded as a Leetcode problem, but it's really just generating every permutation and filter out strings that don't match some condition checks (which I enumerate for them. It's not a blackbox). Asking people to program against this API: boolean login(username: String, password: String) was enough to trip up these people with Masters degree.
The problem with people cheating the system is that it harms candidates like this.
37signals and BaseCamp built products that works for their own processes based on their experience as a software team. They productized it and sold it. I’m not contesting that the product couldn’t be sold.
The issue here is bring driven by growth engagement, giving this impression that it’s about listening to the community. My cynism is that that they don’t care about what makes most sense for the product, but what drives engagement. You can argue what drives engagement is best for the users. That idea is good in theory, but in practice trying to satisfy everyone’s need you will end up not serving any use case well. Go, atleast Go 1, make explicit trade offs that made many people dislike it, but it kept the language simple and excelled at its intended use case.
At any rate, I am cynical that the project here is driven by developer interest as much as it is about impressing VCs.
So it was like a developer saying “I know stars are a dumb and imperfect way to judge a project, but here’s what it is.”
If they hadn’t written this I would think they put too much weight on what’s really not a very important measure.
All of the contributors on this project are from the country that feeds to Infosys. I’ve seen enough inflated resumes from candidates who couldn’t write a loop despite having a masters degree. Ironically, the one candidate from this country I gave raving recommendations for was the one who had bad school grades. This country is also a hotbed for clickfarms and selling fake social media engagement/reviews.
There are several websites where it is possible to buy them.
Deleted Comment
The goal here is to look at something that tells an organisation why chnages to a codebase occurred. Each individual commit can have a nice explanation (in a given human language) of why that specific change occurred. But how does one link other commits, dozens or hundreds or orders of magnitude more.
Can they be accounted for to investors, auditors, regulators?
But equally demanding that commits link to something that links to why, it demands that the rest of the business also link to that something (ie JIRA) so they can explain why they expended time and effort
JIRA or whatever ticketing system, will slowly become the central repository of justification for expense - a great position sure, but also dangerous.
Following on, having some repository of why - of cost drivers - forces not just the software developers but the whole business to justify its activity against the repository. This seems hugely similar to lawyers billing by the 15 minute increment, and indeed a git repo will provide good billing like data too !
But the issue still exists - if I say my activity links to ticket number 1234, then we have a hierarchy (?) of what 1234 links to. The smacks of stories and epics and the whole agile package, but is also a common accounting process
my issue is that this is a neat, backwards looking explanation for what was done. It's not a good way to manage forwards.
And often I find the problem is people wanting to use JIRAs tickets to manage what will be done, not account for what has been done
Ticketing systems are useful for a lot of other things such as keeping track of work on an individual level, or managing project resource allocations on a company wide level, but I'm not sure it's the best tool to do audits and have accountability. It will at best be a secondary source of that data.
Most businesses hide the upfront discussion (or at least keep it to a smaller set of people who have often conflicting incentives for decisions as well (we tend to refer to this as politics but that's a bit like fish moaning about water.)
Anyway the point is that Linux shows how to make good decisions in the open (usually) - a process that I think most would 10x good decision making in most businesses but also lead to huge other sets of problems (worth it in my view but ...).
But Linux does not have a simple way of post-hoc justifying the decisions unless one reads the threads (which is where the recent post of open source journalist at lwn was a great idea)
But things like Jira, external ticket stores are good at providing a hierarchy to post hoc justify the decision - even if they are a terrible way to plan forwards.
So the ideal I guess is some kind of open architecture discussion upfront and some kind of extract and rebuild the rationale from commits (ie in house journalism?)
We know who’s actually under that title cased name. It’s the same monster who hurt us all those years ago
20k stars in a single year is a very impressive feat.
Congrats to the team at Plane, and thanks for this.
I click the star on GitHub when I come across a project that doesn't seem immediately worthwhile, but that I might want to check back on in a few years.
I can't imagine caring about how many stars / likes something has.
In the fintech space I've seen so many startups hire designers to come up with original new designs and user experiences, only to arrive at the exact same design as existing fintech apps.
What is the point of refusing to stand on the shoulders of giants? Pride?
Imo it's also good to realize in this kind of software, patterns and UI are very core to the product, so you are copying the essence of what this company has spend tons of time and resources to develop. Fintech might be different as it's less about UI.
Then there is also a difference between UI patterns and branding. The first: It's good to follow standards and expectations, the second should just not be copied imo.
Another factor is asking money for it, which it looks like they intent to do. I think that makes it even weirder to clone an existing product as now you try to compete and profit from other peoples work.
There is a fine but clear line between inspiration and copying, and imo this crosses the line.
Even if legal I would not use this product for that reason, and imo it reflects poorly on the people doing it.
Personally, I'm perfectly fine as long as they are pleasing to look and nice to use.
- https://spotlight.tailwindui.com
- https://pocket.tailwindui.com
- https://protocol.tailwindui.com
- https://commit.tailwindui.com
- https://mailgo-rho.vercel.app
- https://ioacademy.vercel.app
- https://split-xi.vercel.app
- https://starboard-one.vercel.app
No relations with any. Stumbled on them here on HN and an early customer of TailwindUI.
Deleted Comment
they wouldn't be the first