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" ™.
No, they’re pretty clear - see the quote in my previous comment - it’s absolutely clear about the usage of ports. And you should have courage to admit you were wrong when you were wrong.
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.
The best way to test this hypothesis would be to send a pull request that makes the self-hosting docs clearer. If they accept it then their business does not rely on self-hosting being hard.
That's not a sufficient test, because when put under the gun there's no reason not to believe that a company playing those kinds of games won't take that pull request, temporarily improving the situation, and then simply make no effort to keep it up to date later. Addresses the temporary embarrassment, but not the underlying problem.
Mind, I don't think Plane's one of these. The open-source release seems comprehensive and the doc just seems not very good because the people who wrote it are experienced operators. But the claim being made isn't one that's easily put to rest except through the company in question committing to enthusiastic and comprehensive support that dispels doubts. (And, well--they chose that life!)
That's a sufficient test. It's the community's prerogative to keep it up to date later with further PRs. I don't expect anyone, whether a company or a volunteer, to do ongoing maintenance work on features that don't directly serve them. The thing I'm testing for is whether they'd block someone else contributing a change that doesn't serve that company or volunteer.
Yeah, my experience with working at a startup that did fairly explicitly rely on self-hosting being hard enough that people would pay us instead was that we definitely never had to go out of our way to make that be the case. Making self-hosting easy is a significant amount of continuously ongoing work and we simply underinvested in that. If someone did all that work for us one time we would have happily accepted it.
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 think the parent comment just wanted to say that since this project uses docker compose then it should be a lot simpler to get up and running. Actually running something in production would still require some degree of administration and monitoring based on your use case.
On their webpage it says that you can get started in 30 seconds with their hosted instance. Would be nice if it was as simple to get started with a locally hosted instance.
Of course it is fair. Why would we consider "fair" for an open source offering trying to entice new users?
I don't want a new project, I want to try self-hosting the software. If I am using it and liking it then certainly I would put time and effort into it. If it takes some time fiddling around with docker even to use, well, I have other projects to fiddle.
That goes for all self-hosted, but especially so for a project management tool. I'd be trialing it because I have projects I already need help managing. Adding one more is friction that would likely turn me away.
> If it takes some time fiddling around with docker even to use
Where did you get this from? You do not need to fiddle around with anything to have it working. The only thing that _probably_ requires "fiddling" is the nginx port - and you need to change it only if the default port is already in use. Is it really that difficult nowadays???
That’s certainly the incentive of a company who sells paid hosting.
I think it’s reasonable to provide as close to a one-line / one-action initial install, even for people who are experienced admins. (Those experienced folks can edit/tweak as they like, but having a basic “push this and something sensible happens” goes a long, long way to getting people to succeed in trying the product.)
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.
Building an app that scales to enterprise size is hard. Building an app that does so while also scaling down to single-team size is hard. Every feature you build two backends for is one more thing to go wrong. Writing a sqlite backend for your redis usage, your search, etc... it's not insane, and it's a sign of good Faith, but it's not something that should be expected, either.
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.
> IMHO UI tests are just too difficult to be worth bothering with in most situations.
Yes, that's because you're doing them wrong.
Don't mess around with the "golden master" testing (edit: seems the frontend ecosystem call that "Snapshot Testing" actually, but it's the same) you see bunch of projects do, that compare the old DOM vs the new DOM you accept/deny changes based on component render output. That's a waste of time and won't actually prevent bugs.
Instead, extract the logic-heavy parts out from your components, then put those under unit tests, like any other code you write.
Boom, easy to maintain, verifies your implementation and makes your UI easier and faster to refactor and build in the first place.
In an ideal world one might argue that everything testing-worthy (ie. the logic-heavy parts) is already factored out from the UI components but getting to that point either needs a good amount of foresight and discipline or some a lot of refactoring which is difficult to trust without existing UI tests...
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.
Why do you avoid DRF? It's what keeps me coming back to Django over .NET Core or other API stacks (although I have yet to tilt at RoR in earnest/anger).
I just want to start by acknowledging the demo of basic functionality is fantastic and feels very magical, and–perhaps crucially–it has been a couple years since I gave up on DRF completely. With that out of the way, I've run into issues with it when building actual applications. DRF serializers were absurdly slow. Relations were handled poorly. It steers you away from many of Django's standard features, including the forms interface, which is one of Django's best features. The documentation was lacking for rough patches in the API.
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.
This is not the best practice codebase as I wrote it when I was learning Django. But is it very applied. Any beginner should be able to understand this.
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.
Yes, but Discord does not get indexed by search engines, because it’s not an open platform.
So while it is in the interest of the open source project that as many people going forward can benefit from past Q&A, it is in the interest of Discord to require you to install their client to search.
I grew up with (and love) irc but currently use discord. I find it odd someone who knows irc would list "figure out how to leave a server".
Try explaining the steps to irc to someone who has never used irc before. That will be way more difficult than figuring out discord.
irc also has the downside of "ask question - get nothing" because the guy (who you dont know which guy is "the guy") wasnt online to even see the message. Or "ask the question and wait and hope I dont get disconnected losing any responses they might have answered with"
Discords can setup tickets or question areas as well, which greatly helps
All that said, I prefer docs, wiki, or a forum/subreddit over either irc or discord, but no way would I want to go back to irc
I’m already on irc, so I just join a channel. There’s no membership or obligation.
Joining a discord server is a whole mental decision. And each server is organized differently. So when you join a server you have to figure out where to comment and search.
Joining a server is about as much 'commitment' as joining a channel in IRC. i.e. technically very easy, and socially it entirely depends on the server/channel. For a support one, it's not at all unusual or hard to join and leave again.
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.
It does not "just work," and you're not going to hear from me because I'm not joining yet another Discord server just to wade through searching through chat. Do a free forum. They've worked for 30 years and I might actually find my answer by Googling and won't need to even making a forum account.
I actually entirely agree with you. Nobody needs to take on accommodations they don't want to. And that was kind of my point; you should be aware that choosing Discord limits your participants and also limits your participants ability to engage with your project.
This isn't necessarily a bad thing; may even be a positive aspect. In a quickly changing project, maybe it's good if your documentation isn't too "sticky" and the solution to a problem isn't low-touch "read the docs" but high-touch "ask me so that I can experience the pain points"
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.
I am sure college grads (from decent Indian colleg) can solve this one.
The problem is they have done leetcode style of puzzles all their college life. - mostly control flow, numbers and DP / greedy / graph patterns.
Which is such narrow area of computer science.
They don't understand basics of - operating systems (eg: VMs), compilers (eg: compiled vs source code, optimization), languages (eg: type systems), networks (eg: NAT, firewall), software engineering (eg: writing modular code, version control).
All these things are as Computer Science as leetcode algorithms. These are in the syllabus, at least in a primitive form. But these kids are only tested on leetcode puzzles.
Ask anything deep on these and watch these DSA-generation kids struggle.
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.
I agree on the gamification, but I think they are still useful.
I mean this project has 18k stars that just tells me it’s popular. It’s possible they bought fake stars but at 18k that would be strange.
I think stars are useless for comparing a 17k project to an 18k project and anyone comparing that way would be flagged by me as not so smart.
But it is useful to distinguish something with just a few stars from thousands.
The challenge is that there’s not really a good way to tell what a successful project is short of looking at it closely and using it. I’d like a better measure, but this is what we have.
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?)
There are two kinds of "tickets" - forward looking ones that basically say "we have a problem, please analyse and solve it using software" and a second closely related type that is "we have found the solution to the problem, please apply the solution to our environment"
this is basically the dividing line between dev and ops. and the confusion is what causes so many problems - there is development in support of R&D then there is development in support of ops
one cannot be predicted or sensibly estimated. One can.
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.
> It's not black and white, but cloning a product is just not nice.
Not only is it perfectly fine, it's the only way for competitive markets to function.
Copyright, patent, and trademark laws demarcate the boundaries within which we aim to guarantee enough protection to incentivize investment in truly unique innovations, but outside of those boundaries, we want markets converge to common product standards and establish category-wide conventions. That enables continuous marginal innovation without each entrant having to reinvent the wheel from scratch every time.
I'm not sure anyone, Apple included, is better off today because they managed to shut down GEM and ended up killing Digital Research. I'm not sure anyone, AT&T included, would be better off today if the BSD and GNU projects and Linus Torvalds had never aimed to create clones of Unix.
Creating FOSS clones of commercial products is where much of the foundational modern software came from, and forking existing projects to add your own features is an essential element of FOSS software.
You're naturally free to eschew this project for the reasons you cite, but I don't think your opinion establishes good general principles. Markets, technology, and society as
a whole function precisely because people do copy what works from each other and add then add their own innovations incrementally.
Fully agree with the point that branding should not be copied. I should have been more clear but my comment pertains mainly to UI and UX of a product. If you're copying branding (something that offers no functionality, just style), that is just a dick move.
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.
sorry, you seem to be right. I got confused by their github presence which despite the name, doesn't contain their product.
https://github.com/linear/linear
All of these companies are basically soft scams. They go against the fundamental ethos of open source. It's a shame really. Also I wonder how many of these rankings are not gamed by Indian bot farms.
I believe one major difference between GH issues and Jira tickets in an enterprise setting is the lack of time estimating and work logs in GH.
I know that a lot of enterprises use the time estimates combined with the work log in Jira to time box sprint cycles based off of how long it took to complete past tickets.
Figured it out, but self-hosting was overly complicated. Does a simple app like this really need nine containers? I prefer the simplicity of something like kanboard.net that has similar features and is much more customizable.
This was a good read, albeit very long. I ordered my meal, finished it, and got in my cab before finishing this article. Congrats on the growth.
Do any companies decide to switch away from Jira onto Plane or is it only new orgs/teams? Because I find that there's a lot of integrated tooling around Jira that keeps people there.
GitHub stars are for bookmarking and most people add it and never open the repo again, I don’t know why it’s seen as some sort of an achievement or a successful IPO, it’s a bookmark, github should change it to a bookmark icon at this point.
Flexibility of custom workflows, integrations with third party systems, being able to track down tickets across the whole lifetime (documentation, source control, bug reports, who did what, reporting).
Yes, it is a huge beast, because big corps have huge complex workflows.
And that's what everyone else doesn't want, what makes it such a PITA to use for those that don't need it. Essentially I think anyone looking for or interested in an 'alternative to Jira' exactly doesn't want that mess to follow them away from it.
But plenty of people/companies in the target market of the simpler tools end up using Jira anyway.
This is like objecting to a fairly lightweight orchestration tool calling itself a 'Kubernetes alternative' - it is an alternative, it won't necessarily fulfil all needs of everyone using Kubernetes (resp. Jira), but it will for a lot of them, a lot of them don't need everything it's offering anyway. Of course they're going to use one of the most well-known players to paint the picture of what sort of thing the product is.
How are you finding it compared to Jira? The mention of Jira in the title puts me off as I hate everything about Jira, but I get that they may just be using it here to help casual observers understand what the software does.
They are for sale https://buygithub.com/product/stars/ so it is very suspicious in this case, when there is a sudden spike, a marketing blog mentioning them.
My personal experience is that most stars on my projects come from empty accounts that star random stuff to avoid getting detected when they star the projects that paid.
As an alternative to dedicated planning tools, you could try simple journalling to eke through your thinking.
Just create a github repository (privately if you want) and update a README.md file and journal at the end chronologically or reverse chronologically depending on how you think of your journal.
I've been doing this since 2013 and it really helps me get things done.
Because it's the ONE place you go to to plan and see what you need to do, you don't have to remember hundreds of different buckets where information goes and is forgotten. It's all there in one place.
I am using a (home-made) work management software for my personal projects (programming or otherwise). It's just good organization. Allows me to get done more than I would be able to do relying just on my brain. And I can always ignore it if I don't feel like working.
He just means a kanban board to keep track of what's not done, a way to attach notes to tasks, and a backlog. He's not going to assign points to brushing teeth and packing lunches...
Ye. A good lesson in dishonesty and collective delusion.
Honestly, probably a good thing to learn kids how to verbally fake progress and work from an early age and make them self sound helpful and important. As long as they are told it is only OK to lie during Scrums.
If the OP had said private projects, I would agree but he mentioned private tasks. So I imagined him using the tool for daily chores and such. but I think your statement make more sense.
Didn't know Linear before, but indeed it looks like a lot is coming from there, even their terminologies (i.e. "Cycles", etc.). Linear does seem to have more integrations, but less issues (250 max.) on their Free tier.
