Live data from Hacker News

Leantime: Open-Source Jira Alternative

github.com

11–20 of 85 posts

Re: Leantime: Open-Source Jira Alternative

#11

[flagged]

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.

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.

Re: Leantime: Open-Source Jira Alternative

#13
post #5

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.

[flagged]

Re: Leantime: Open-Source Jira Alternative

#14
post #5

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.

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?

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.

Re: Leantime: Open-Source Jira Alternative

#15

Earlier quoted context omitted.

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?

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.

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.

Re: Leantime: Open-Source Jira Alternative

#17

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?

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.

Re: Leantime: Open-Source Jira Alternative

#19
post #17

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?

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" sc…

> 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?

Re: Leantime: Open-Source Jira Alternative

#20
post #5

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.

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.

Post reply on HN