[HN Gopher] Leantime: Open-Source Jira Alternative
___________________________________________________________________
Leantime: Open-Source Jira Alternative
Author : intheleantime
Score : 139 points
Date : 2023-10-09 12:25 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| phoronixrly wrote:
| Thank you for this, it looks great! I also admire your choice of
| license. We need more fresh AGPL software.
| intheleantime wrote:
| Thank you for the feedback! Don't hear a lot of people say
| anything positive about AGPL these days... :)
| jroseattle wrote:
| I see marketing-speak for how this is so much easier than other
| tools like JIRA (which we use.) However, I'm not finding details
| about how this is accomplished.
|
| What are the key differentiators in how this is easier specific
| to those that use JIRA?
| gloriaf wrote:
| Great question and thanks for pointing it out -- we'll make
| sure to address this on the website.
|
| In a Jira workflow, there's a lot of customization required and
| a lot of thought needed to go into how to set up your workflow.
| Leantime is intended to be "opinionated" in the way that it's
| already set up -- each work function already has a home. The
| thing you have to decide is how you want to see the tasks.
|
| Our "home" screen is intended for individual users to have pre-
| defined organization and not needing to set up their own
| dashboards either.
|
| The other approach we do differently is to work to engage ICs
| in the value of the work and we do that by making the goals and
| work more clear. Some of this is still being developed out and
| rounded out better by our AI features -- which can be better
| read about here and how we view it in relationship to our own
| ADHD and the features behind it...
| https://leantime.io/2023/07/30/the-top-digital-planner-
| for-a....
|
| Lastly, for Confluence fans, we come default with docs and (on
| cloud) we have whiteboards. Some of which will be coming out in
| plugins to OSS here soon.
| jroseattle wrote:
| > In a Jira workflow, there's a lot of customization required
| and a lot of thought needed to go into how to set up your
| workflow. Leantime is intended to be "opinionated" in the way
| that it's already set up
|
| I'm not sure what this means entirely, but across our
| projects we have some with different workflows than the
| others. These are necessary in that we have certain workflows
| that must meet compliance requirements, and those workflows
| are the best way to ensure we execute those. In other
| projects, they are less onerous and apply to different kinds
| of work (so, different workflows.)
|
| > Our "home" screen is intended for individual users to have
| pre-defined organization and not needing to set up their own
| dashboards
|
| This is good, but we generally keep our exec leadership out
| of JIRA (they don't really have the context for the details.)
| Our users can design their own dashboards, but that's a
| personal preference. We use the standard views.
|
| > making the goals and work more clear
|
| I would prefer to see more fall-into-the-pit-of-success for
| the equivalent of JIRA stories to be more oriented toward the
| outcome or feature or capability, as opposed to the
| accounting/I-got-receipts feeling I get from JIRA. While
| story points are fine, I prefer a focus on clarity and a
| better measurement for effort than the subjectivity of a
| team's interpretation of the fibonacci sequence.
|
| > for Confluence fans, we come default with docs and (on
| cloud) we have whiteboards
|
| So, Leantime includes a markup engine as well as a whiteboard
| feature? If I already have a deep investment in other tools
| that do those things, how do they integrate?
| intheleantime wrote:
| The problem most users face when starting out with Jira (or
| any other tool for that matter) is they don't know how to
| get started with a process. Leantime starts with some pre-
| defined worfklows following industry best practices. You
| can still update statuses and other items on a per project
| base later once you are comfortable using the tool.
|
| Something that all pm tools have in common these days is
| that they are glorified task lists with different
| visualization options. This is not project management. In
| Leantime you track and work towards goals/outcomes, you see
| your metrics change and know what impact your work has.
| Additionally we added a variety of research/strategy
| focused boards such as Lean Canvas, Business Model Canvas,
| SWOT etc to allow you to define products and features
| deliberately and in a central location. This helps to align
| your entire team.
|
| The docs (while admittedly not as powerful as confluence)
| keep your documentation where it needs to be (with the
| project) rather than having to switch between sites.
| jroseattle wrote:
| Thank you for the responses, I'll dig further into the
| service.
| crabbone wrote:
| I keep looking at various JIRA alternatives, but no good finds so
| far. This is definitely not it.
|
| I don't really like the idea of bug tracker as a sort of a GUI
| program that acts like time management software, i.e. focuses on
| planning work, tracking how much effort was spent, ability to add
| notes to tasks etc.
|
| My ideal bug-tracking software works more like Git: it has a
| server-client relationship where clients query the database with
| predefined set of commands, while at the same time it has
| programmable interface facing test code. This interface should
| enable tests to do things like:
|
| * figure out what components need tests to run against them when
| a particular feature branch sees a code update.
|
| * extract history of tests running against a defined group of
| features.
|
| * manage association of tests and program components.
|
| * manage test sets that aren't feature-related (eg. nightlies).
|
| JIRA kind of has this database / query component, but all the
| functionality above needs to be built on top of it. And the data
| organization of JIRA relies on issues as the basic unit, where
| I'd like the basic component to be "features" (similar to how
| branches are in Git).
|
| My biggest problem with the currently popular approach (emphasis
| on time management) is that it's very informal and unstructured
| when it comes to testing, poorly automated and poorly integrated
| with other development tools to the point that it makes it both
| easy to forget to do the necessary stuff and a very repetitive
| chore to keep the necessary stuff up-to-date, while it's clear
| that it's possible to automate it.
|
| The attempts to automate this process by adding bots that manage
| issue life-cycle or generate trivial fixes / merge trivial PRs
| isn't the way to solve the problem, IMO because this automation
| is stupid and has a potential to cause harm. Instead it needs to
| be very tightly integrated with VCS (but, let's be honest, with
| Git) to the point that such configuration would require minimal
| effort on the part of the admin and be vendor-independent, and,
| most importantly, be feature-oriented to mirror how programmers
| conceptualize the development of their program.
| intheleantime wrote:
| I really appreciate your feedback here and I see where you're
| coming from and can agree if you're looking at Jira as a purely
| bug tracking / development tool.
|
| Unfortunately, and I think important to call out -- is that
| most companies are trying to use these tools as a "catch all"
| -- "a one in all solution that solves everyone's problems" and
| then ultimately, half of the company refuses to use the tools
| because it's too focused on one user group.
|
| Our long term approach is really about making work and getting
| sh*t done as a relevant part of the PM process and less on time
| management. Time management is part of organization but people
| want to care about what they're building and why... something
| that can be absent in a lot of orgs and even in how we organize
| ourselves in small teams, startups or small businesses.
|
| What I do hear and think would be interesting -- is
| incorporating a plugin more specific to your workflow mentioned
| here... because absolutely, tighter QA, etc, is vital and there
| are things not otherwise easily replicated as part of a dev's
| flow. We, otherwise, don't have any current intentions to use
| "bots" in a way that automates things that people should really
| still be overseeing.
| no_wizard wrote:
| I can recommend Linear[0]
|
| No affiliation. Simply, I really like how it works, and its a
| great interface as well. Really gets out of your way, has solid
| integrations and a good API for building your own
|
| [0]: https://linear.app/
| ramzez wrote:
| I quite liked it but last time I checked there was no GitHub
| integration and that's I would say one of the top features, as
| every card we complete we want to have PR/Commit attached to it
| in development lifecycle.
| intheleantime wrote:
| Thanks, and I agree. We spend the last 4 months working on a
| plugin infrastructure including events, api, plugin management
| etc so that we can now focus on building integrations. The next
| 3 months or so will be heads down integration work.
| pagutierrezn wrote:
| TBH it looks pretty much like Redmine: https://www.redmine.org/
| (also open source) configured with the appropiate set of pluggins
| intheleantime wrote:
| Huh, not sure I would agree with that.
|
| We have some overlapping feature set but I would argue Leantime
| looks a bit better but I may be biased :D
|
| The key differentiators are our goal and strategy tracking
| though.
| jdlyga wrote:
| You're preaching to the choir with Jira alternatives. For devs,
| Jira more often gets in the way than helps. We're ok with a
| minimal set of features. In order to really get traction, you
| need to sell PM's and leadership types.
| intheleantime wrote:
| I agree, there is a real challenging disconnect between
| messaging for PMs/Leaders vs individual contributors and it
| boils down to organization size. Small companies and startups
| tent to be a lot more democratic about their choice of tools
| where as large organizations tend to be more pm/leadership
| driven with input from ICs.
|
| Right now we are targeting the smaller companies that don't
| have a lot of PM experience or resources available. The dream
| being the slack story of IC driven product adoption :D
| hyggetrold wrote:
| Looks nice - major feature request / design ask / feedback.
|
| The current "kanban board" looks basically the same as JIRA's and
| it's what a lot of people are familiar with. I would love love
| love to see a visualization that puts all current planned stories
| into a single vertical column and groups them by status. Done at
| the top, ready for review underneath, then in progress, and not
| started. It's a way more compact view of stories and better use
| of real estate.
|
| For prior art look at Pivotal Tracker.
| latchkey wrote:
| PT is the gold standard imho. Mainly around the fact that it
| does such a great job tracking velocity. The primary issue is
| that outside of developers who've worked at Pivotal (I have),
| most people don't understand the process of using PT.
| intheleantime wrote:
| Thank you for the feedback! Our table views as well as the list
| views allow grouping by status and will show the vertical
| groups as you described. Is that what you are looking for?
| There are a couple screenshots on the repo. (Though they show
| the group by milestone, status is possible the same way)
| hyggetrold wrote:
| What I'm hoping for is beyond what I currently see on the
| repo - I want a _dense_ view of story information. 'latchkey
| got what I meant in the other comments below my top comment.
| Definitely recommend you look at PT and see what it does. I'm
| not suggesting you make a carbon copy but there's a lot to
| learn from the PT model.
| latchkey wrote:
| PT goes far beyond just grouping information. Coming from
| just using Jira, it is lightyears ahead of a standard issue
| tracking system.
|
| I suggest you spend some time diving deep into PT and
| understanding how it tracks velocity and encourages writing
| useful stories.
|
| The documentation on the site is pretty good and there are a
| ton of googleable resources.
| stuckkeys wrote:
| Leantime.io so heavy with trackers that the page fails to load
| lol. I am using Pihole btw.
| intheleantime wrote:
| We got Google Analytics and Clarity on the site. Not sure that
| is out of the ordinary. The site should still work with pihole
| though, so I'll take a look at that.
| greenflux wrote:
| "We take the WTF out of managing work" -nice. I love the
| animation with this. The UI of the product looks pretty good too.
| Glad to see you have row grouping on the table view.
|
| Another good open-source Jira alternative is https://plane.so/ .
| They also have a free cloud plan with unlimited users.
| intheleantime wrote:
| We feel like the free cloud plan is the way to go -- by keeping
| our core features free, we think it's the "level up" PM
| features that start to bring value worth paying for.
| az09mugen wrote:
| Another open source alternative for jira is taiga :
| https://taiga.io/
| broskees wrote:
| I tried Taiga. It was a little overly opinionated for me (like
| it's decision to force me to use story points). I used leantime
| now and its customizable basically any way i need it to be via
| plugins.
| az09mugen wrote:
| Thanks for your feedback
| kyaghmour wrote:
| [flagged]
| intheleantime wrote:
| How come? The practical difference between AGPL and GPL is that
| the term "distribution" now includes distribution via network
| aka SaaS.
|
| Now I can see how this might be a problem for code libraries,
| infrastructure system etc but the only reason to worry about
| AGPL in an end user application context is the desire to
| repackage and sell commercially. Aka do the Amazon thing.
| jddj wrote:
| It's the obligatory _copyleft is not free software_
| astroturfing comment.
|
| Prompt is here: https://news.ycombinator.com/item?id=37611571
|
| --
|
| More seriously and charitably though, affero is vaguely scary
| because there's a (perhaps misunderstood, but I can
| understand) feeling that if you cooperate with it in any way
| in the backend and then a value-added product of that
| interaction makes it to a user of yours then you're up for
| copyright infringement.
|
| This isn't a reason not to release under affero, nor is it a
| bad thing that entities producing non-free software need to
| take care what they leverage, but I can see how the decision
| could be made to avoid using agpl style software whereever
| possible to err on the side of caution.
|
| A good example is ghostscript. At what point does an app
| converting PDFs to images (to display thumbnails, for
| example) as a small part of its workflow become an aggregate
| of that free software? According to the faq it ends up being
| a fairly subjective question of form and intent. Syscalls or
| static linking? Etc.
| leanable wrote:
| [dead]
| broskees wrote:
| What's wrong with AGPL?
| kyaghmour wrote:
| Affero is effectively bait-and-switch.
| mqus wrote:
| Which license is then not bait-and-switch? Imho it is only
| that if they put all contributors under CLAs (they do) and
| even then this is a problem with the CLA, not the AGPL.
| intheleantime wrote:
| That is BS. Affero is not any different to GPL but the fact
| that network distribution is included in its definition of
| "distributing software" and having to relicense under the
| same license.
|
| Where do you even get this from?
| kyaghmour wrote:
| Call it what makes you warm and fuzzy.
|
| Here's from Leantime's own FAQ
| (https://leantime.io/pricing/): "We are GPL-2 and require
| code updates to be submitted back to the core code. We
| offer Enterprise licenses if you'd like to modify the
| code to use for company use."
|
| The pattern is effectively always the same. Many
| companies use this license to offer a free version while
| offering a "way out" by providing an "enterprise
| license". They get you hooked because it's open source.
| But as soon as you want to customize and keep the
| changes, they want to charge you.
|
| It's a matter of personal choice. I choose NOT to use any
| Affero licensed software if I can help it.
| intheleantime wrote:
| I think there is a misunderstanding of the license(s)
| here:
|
| "But as soon as you want to customize and keep the
| changes, they want to charge you"
|
| Neither GPL nor AGPL require you to submit anything back
| (or charges you) for changes made to your system for your
| own usage. Even if it is within a company. It is about
| preventing distributing derivates to the public under
| closed source licenses.
|
| You can even have and keep changes (unpublished) for you
| entire organization without having to contribute back. It
| is when you distribute it back to public that you have to
| license the changes under the same license.
|
| There is no baiting here.
| kyaghmour wrote:
| Have you actually read the Affero license?
|
| From section 13: "Notwithstanding any other provision of
| this License, if you modify the Program, your modified
| version must prominently offer all users interacting with
| it remotely through a computer network (if your version
| supports such interaction) an opportunity to receive the
| Corresponding Source of your version by providing access
| to the Corresponding Source from a network server at no
| charge, through some standard or customary means of
| facilitating copying of software."
|
| Your statement is incorrect: "You can even have and keep
| changes (unpublished) for you entire organization without
| having to contribute back. It is when you distribute it
| back to public that you have to license the changes under
| the same license."
|
| Even * _HOSTING*_ a private instance puts you under
| Affero. Even if the instance isn 't public, if you so
| much as have a contractor remotely accessing an internal
| deployment of a customized Affero-licensed software then
| they can ask for this customization.
|
| https://www.gnu.org/licenses/agpl-3.0.en.html
| intheleantime wrote:
| "You can even have and keep changes (unpublished) for you
| entire organization " -- add to that that the
| organization should have access to the source code, yes.
| That doesn't mean that you need to publish the code
| outside of your organization.
|
| " Even if the instance isn't public, if you so much as
| have a contractor remotely accessing " -- Correct, now
| you are distributing the software to the "public"
| external to your own needs.
| kyaghmour wrote:
| "interacting with it remotely through a computer network"
| isn't "distributing", it's hosting. Companies providing
| software under Affero licenses love to play with words.
| That's fine. It remains a bad license for users. I choose
| not to use any software licensed under its terms.
| leanable wrote:
| [dead]
| mqus wrote:
| > But as soon as you want to customize and keep the
| changes, they want to charge you.
|
| But afaik you only have to provide the source to your
| users? You're never obligated to contribute back? So if
| you make in-house changes, this shouldn't matter much.
| bilekas wrote:
| I am really not savvy with the open source licenses, but why
| did you dislike the Affery license model ?
| _ZeD_ wrote:
| this tool cannot be jeff'd
| kyaghmour wrote:
| Here's from Leantime's own FAQ
| (https://leantime.io/pricing/): "We are GPL-2 and require
| code updates to be submitted back to the core code. We offer
| Enterprise licenses if you'd like to modify the code to use
| for company use."
| johandicap wrote:
| Under GPL-2, is the company not allowed to modify the code
| for internal (company) use given they avoid publishing or
| distributing these modifications?
| graypegg wrote:
| I love the confetti and easy tech (just PHP and MySQL) for self
| hosting!
|
| But browsing the marketing site, you have a lot of AI tools for
| prioritizing lists. This is 100% the place where I don't want
| things to move without me knowing. My biggest complaint with
| JIRA/Monday/etc is they have some entity representing "tasks",
| that's displayed in a million different perspectives. Finding a
| thing is usually what I want to do and I hate it when stuff
| disappears or changes in a view I was using.
|
| No matter how good your tool is at prioritizing, it will be wrong
| some percentage of the time and while it's a little annoying to
| skim a big unsorted unchanging list, it's even worse when it
| changes ALL the time.
| intheleantime wrote:
| Thanks for the feedback. This may have not come across clearly
| enough on the website. The AI prioritization is an optional
| mechanism (toggle) to help individual users prioritize the
| tasks that have already been assigned to them using signals
| like task sentiment (how do you feel about a task), priority
| etc.
|
| The priority field is not changed as part of that function. I
| agree that AI cannot be the primary prioritization mechanism.
| All it can do is augment existing processes and help
| individuals be more effective.
| 6keZbCECT2uB wrote:
| How does the tool ingest task sentiment? As a developer, I
| would never put in writing that I'm less than enthusiastic
| about any task.
| wredue wrote:
| I find that the AI is better at prioritization and triage than
| the human support.
|
| But then, for some reason, whenever support fails to read their
| tickets, they just dump the ticket on to my queue. So I could
| just be being salty, or seeing fewer misses because the ai is
| better at failing the triage.
| dmazzoni wrote:
| Can you talk about your tech stack?
|
| One of the biggest complaints about Jira is how slow it is. While
| I'm really interested in potential alternatives, I'm curious if
| you think PHP might be a bottleneck.
|
| If I follow a direct link to either a single existing issue, or a
| create new issue page, how fast does the page load?
|
| How well does the backend scale to 100k or 1M issues?
|
| How well does the frontend scale if you try to open a view with
| 1k or 10k issues?
| intheleantime wrote:
| Hi, thanks for the question.
|
| It is a simple PHP application using Mysql as the database
| backend. We are using a domain driven design architecture
| across the application and decided to skip the slow ORMs in
| favor of a repository layer with hand written sql.
|
| We are framework agnostic to not be locked into any flow but
| you will see classes from Symfony and Laravel. The goal has
| always been to make Leantime as lean as possible to allow
| hosting it on any shared host out there. That means we don't
| use any exotic extensions or OS features. You can run it safely
| on the smallest Godaddy instance if you wanted to.
|
| We recently introduced htmx into the stack to offload some of
| the rendering back to the server and we love it.
|
| PHP itself is really not a bottle neck anymore especially since
| PHP 8.0
|
| We haven't had a chance to run a lot of large scale load tests
| yet so take the following with a grain of salt but a direct
| Task hit currently takes about 2.08 sec to load on our
| production site. (that includes javascript processing time as
| it loads in a modal)
|
| I know we have instances with thousands of tasks and users in
| the wild and generally performance is not an issue we get
| reports on on our github repo.
| intheleantime wrote:
| PS I forgot to mention that we have Sentry profiling. Full
| Application load (php side) P95 is 120.9ms and P99 is
| 634.11ms
| alexchamberlain wrote:
| 2 seconds is pretty slow, especially for a single item lookup
| which is about as good as it gets for database lookups etc.
|
| Where is that time spent?
| intheleantime wrote:
| That is the entire cycle from browser, to server and back +
| js execution.
|
| As mentioned in a comment below php execution including db
| call is: P95 is 120.9ms P99 is 634.11ms
|
| Which means the rest is DNS lookups and js execution.
| jeo123 wrote:
| Not touching this AGPLv3 software. Every company I work on ban
| any software with that license. This will be a niche project or "
| propietary" to orginal developers. It is open-source for users
| using. Unlikely to see any open source developers contributing it
| back. Good luck.
| intheleantime wrote:
| I mean, we have 89 contributors... What are your concerns with
| AGPL? The practical difference is the clause that SaaS
| distributions require to be licensed as AGPL as well. Would you
| plan to take this, add commercial features and repackage as
| commercial closed source system?
| mqus wrote:
| As someone who would love to contribute: AGPL means nothing
| if I have to sign a CLA that gives you the ability to switch
| licenses on a whim. You will have much less contributors for
| this reason alone, while also scaring away customers.
| mcny wrote:
| > As someone who would love to contribute: AGPL means
| nothing if I have to sign a CLA that gives you the ability
| to switch licenses on a whim. You will have much less
| contributors for this reason alone, while also scaring away
| customers.
|
| but then AGPL is not the problem, CLA is, right?
| hedora wrote:
| Nothing stops you from forking it. I also dislike CLAs from
| a developer perspective, but I understand why companies
| require them. In particular, the CLA is likely going to
| make investors happy, and the investors pay the bills, at
| least initially.
|
| If the investors eventually stop paying the bills (or if
| the set of people that want to contribute is larger than
| the set of people the investors will pay), then fork it.
| This seems like a win-win, in that developers win because
| they get Free tools, and in that developers win because the
| get paid well to develop open source software.
| intheleantime wrote:
| Not just investors. I had long conversations with legal
| about that to better understand why it is necessary.
| Don't get me wrong, I don't like it either but here is
| the deal:
|
| - I want this project to be a success (and open source) -
| To make it a success I need to live - To live I need to
| pay for food
|
| Commercialization in OSS is pretty straight forward as
| there aren't many options: - Support, managed hosting,
| paid plugins/features, sponsors.
|
| With the exception of Sponsors, all of these require a
| number of changes to code and infrastructure that should
| not be public and this would not be possible without a
| CLA.
|
| Ergo: CLA -> OSS Developer gets to live.
|
| Yes, it does open the door to license changes and that is
| a whole other story. But what it boils down to is that
| funding an OSS project without a CLA is basically
| impossible.
| cybrexalpha wrote:
| It spooks company lawyers. The AGPL's "license transference
| at a distance" is scary from a legal risk point of view. Many
| corporate legal departments forbid it, or at least getting
| the exception approved by legal is so painful as to not be
| worth it.
| intheleantime wrote:
| Correct but the reason for that is the fact that all of the
| sudden companies are forced to contribute back if they want
| to offer commercial software on top of the labor of OSS
| projects.
|
| Again, I agree with the reasoning for libraries, devTools,
| infrastructure etc given that those libraries end up in
| commercial products. However in the case of full fleshed
| enduser applications AGPL is a great protector against the
| amazons of the world.
| hedora wrote:
| For device manufacturers, GPL3 is just as onerous as
| AGPL.
|
| As an end user, I'd rather not use GPL3 software that has
| a carve out that enables the software to be used by
| privacy hostile service providers that routinely force-
| upgrade their user customers to worse versions of their
| systems, but that prevents people from just sticking a
| customized version of the software on a gizmo and selling
| it to me.
|
| After all, I can least air-gap and not upgrade most
| gizmos.
|
| Anyway, I wish they'd rename AGPL to GPLv4 so the
| infamous "or later" clause applied to it.
| leanable wrote:
| [dead]
| edg-l wrote:
| I like to quote the gnu article on pragmatic idealism:
|
| > The GNU GPL is not Mr. Nice Guy. It says no to some of the
| things that people sometimes want to do. There are users who
| say that this is a bad thing--that the GPL "excludes" some
| proprietary software developers who "need to be brought into
| the free software community."
|
| But we are not excluding them from our community; they are
| choosing not to enter. Their decision to make software
| proprietary is a decision to stay out of our community. Being
| in our community means joining in cooperation with us; we
| cannot "bring them into our community" if they don't want to
| join.
|
| What we can do is offer them an inducement to join. The GNU GPL
| is designed to make an inducement from our existing software:
| "If you will make your software free, you can use this code."
| Of course, it won't win 'em all, but it wins some of the time.
|
| Proprietary software development does not contribute to our
| community, but its developers often want handouts from us. Free
| software users can offer free software developers strokes for
| the ego--recognition and gratitude--but it can be very tempting
| when a business tells you, "Just let us put your package in our
| proprietary program, and your program will be used by many
| thousands of people!" The temptation can be powerful, but in
| the long run we are all better off if we resist it.
| leanable wrote:
| [dead]
| vijaykiran wrote:
| What exactly is the problem with AGPL if you just want to use
| it within your environment/company? It is no different than
| other OSS licenses in that sense.
| leanable wrote:
| [dead]
| broskees wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-10-09 23:01 UTC)