Leantime: Open-Source Jira Alternative(github.com)
github.com
Leantime: Open-Source Jira Alternative
https://github.com/Leantime/leantime
84 comments
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.
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.
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.
This is something we thought about a lot as well; right now it's just an emoji rating. Once set the picker changes to a checked mark and is not visible to others. The data is stored in the db but not visible to others in the system.
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.
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.
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.
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
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
TBH it looks pretty much like Redmine: https://www.redmine.org/ (also open source) configured with the appropiate set of pluggins
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.
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.
To each their own. HN users prefer light sites like HN itself so Leantime with material styles is not ideal for lightness. Pivotaltracker and Redmine are really nice with basic-looking UI.
Though I've just set up Leantime in my homelab for todo list/calendar.
Though I've just set up Leantime in my homelab for todo list/calendar.
The license on this is curious. They claim AGPLv3 and position themselves to be open source, but it's really Open Core with them being the only party who can make privileged non-AGPL plugins. Or, perhaps, if you fork it and add your own non-AGPL stuff only to the app/plugins/ subdirectory, you might also be in the clear? The exception is poorly worded.
And then the README and the LICENSE files list different exceptions to AGPL. I'm not even convinced that mishmash of exceptions constitutes a valid license.
https://github.com/Leantime/leantime/blob/a28ed345782a7bf8a0...
https://github.com/Leantime/leantime/blob/a28ed345782a7bf8a0...
And then the README and the LICENSE files list different exceptions to AGPL. I'm not even convinced that mishmash of exceptions constitutes a valid license.
https://github.com/Leantime/leantime/blob/a28ed345782a7bf8a0...
https://github.com/Leantime/leantime/blob/a28ed345782a7bf8a0...
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.
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.
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)
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.
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.
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.
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.
"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.
Another good open-source Jira alternative is https://plane.so/ . They also have a free cloud plan with unlimited users.
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.
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?
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.
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.
> 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?
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?
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.
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.
Thank you for the responses, I'll dig further into the service.
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.
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.
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.
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.
Yeah, what they're asking for needs to be an app / integration / plugin that ties different solutions together. A kitchen sink approach will forever be mired in gigantic codebases that a single group or company can't coherently maintain [at a reasonable time or cost], and a marketplace of solutions is better able to evolve. We need more simple and specific tools that don't do much, but can be combined with other simple specific tools.
Take branching models for example. Why do we have different "branching models" that work certain ways? Firstly because somebody built a tool that works a certain way (Git) and people need to figure out how to use it. Secondly because how you use it has a direct effect on other things, so you need some coherent model for how your group will use it. And thirdly because there's a few specific ways of using the tool, so we write those down and give it a name. Nobody set out to design these branching models, they just evolved as people started using the tool in different ways.
The same should (and kinda does) happen with project management, time tracking, issue/bug/work tracking, documentation, incident response, budgeting, etc. But mostly it's within one ecosystem (Atlassian's) or another. It should really be more general, and it should be easier to integrate different solutions and build on top, and from there new standard patterns can emerge such that we don't have to be stuck into one ecosystem.
Take branching models for example. Why do we have different "branching models" that work certain ways? Firstly because somebody built a tool that works a certain way (Git) and people need to figure out how to use it. Secondly because how you use it has a direct effect on other things, so you need some coherent model for how your group will use it. And thirdly because there's a few specific ways of using the tool, so we write those down and give it a name. Nobody set out to design these branching models, they just evolved as people started using the tool in different ways.
The same should (and kinda does) happen with project management, time tracking, issue/bug/work tracking, documentation, incident response, budgeting, etc. But mostly it's within one ecosystem (Atlassian's) or another. It should really be more general, and it should be easier to integrate different solutions and build on top, and from there new standard patterns can emerge such that we don't have to be stuck into one ecosystem.
Well, if you are going in the direction of tighter QA integration, there are several interesting things that tools like JIRA are missing, and sometimes plugins try to complement, but not quite.
If we accept that bug tracker is to be a planning program, then QA usually needs a lot more than a free-form JIRA story can offer. QA really needs what they call "test plans".
Usually, to test a feature QA, beside writing tests, needs to organize it as an activity, which might be also relevant to release management, but in general may touch on other product life-cycle phases. This comes from the fact that some rare activities performed by QA are not worth automating, and sometimes are very hard to automate (eg. uploading the program to some kind of third-party store, where it needs to be approved by the store's moderators, sometimes requiring back-and-forth with developers / QA / release management). Other typical QA tasks would include producing reports, producing or studying release notes, studying feature definitions, and perhaps, scheduling meetings with people responsible for the said features.
Sometimes QA needs to run a proper scientific research, with all that entails: research planning and execution which are often also quite regimented, but would need to be built on top of tools like JIRA which don't offer any structure to the story, and the existing superstructures of stories (eg. epics or various links between issues) don't cover because they act more like arrays or trees, where what you want is structs / documents.
On the other side, project managers need a structured and formal way to deliver product requirements to R&D, from which QA will later have to produce tests. Again, free-form issues aren't enough here because the structure will have to be written down as free-form text, but will be very repetitive, unverifiable and lead to feature planning mistakes.
If a bug tracker offered a more structured approach to feature planning by formalizing the aspects of this process, this may lead to generation of program stubs as well as test stubs (the promise UML made but never really delivered).
If we accept that bug tracker is to be a planning program, then QA usually needs a lot more than a free-form JIRA story can offer. QA really needs what they call "test plans".
Usually, to test a feature QA, beside writing tests, needs to organize it as an activity, which might be also relevant to release management, but in general may touch on other product life-cycle phases. This comes from the fact that some rare activities performed by QA are not worth automating, and sometimes are very hard to automate (eg. uploading the program to some kind of third-party store, where it needs to be approved by the store's moderators, sometimes requiring back-and-forth with developers / QA / release management). Other typical QA tasks would include producing reports, producing or studying release notes, studying feature definitions, and perhaps, scheduling meetings with people responsible for the said features.
Sometimes QA needs to run a proper scientific research, with all that entails: research planning and execution which are often also quite regimented, but would need to be built on top of tools like JIRA which don't offer any structure to the story, and the existing superstructures of stories (eg. epics or various links between issues) don't cover because they act more like arrays or trees, where what you want is structs / documents.
On the other side, project managers need a structured and formal way to deliver product requirements to R&D, from which QA will later have to produce tests. Again, free-form issues aren't enough here because the structure will have to be written down as free-form text, but will be very repetitive, unverifiable and lead to feature planning mistakes.
If a bug tracker offered a more structured approach to feature planning by formalizing the aspects of this process, this may lead to generation of program stubs as well as test stubs (the promise UML made but never really delivered).
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/
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/
Thanks. I'll take a look.
On the surface: it's the same as JIRA, Mantis, RedMine, Track etc.: a time-tracking GUI program. Not at all what I wanted. There's nothing bad about being a time-tracker, just not what I need.
On the surface: it's the same as JIRA, Mantis, RedMine, Track etc.: a time-tracking GUI program. Not at all what I wanted. There's nothing bad about being a time-tracker, just not what I need.
Another open source alternative for jira is taiga : https://taiga.io/
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?
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?
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.
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.
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?
Where is that time spent?
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.
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.
PS I forgot to mention that we have Sentry profiling. Full Application load (php side) P95 is 120.9ms and P99 is 634.11ms
Thank you for this, it looks great! I also admire your choice of license. We need more fresh AGPL software.
Thank you for the feedback! Don't hear a lot of people say anything positive about AGPL these days... :)
Nice to see an open source project posted here that is actively being developed. A lot of the time I go to the pulse and it'll have 500 lines of code added over a month, if it's lucky. This has 50,000 lines which is cool.
Thanks! There is so much more to come!
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.
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.
[deleted]
Leantime.io so heavy with trackers that the page fails to load lol. I am using Pihole btw.
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.
kyaghmour(3)
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?
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.
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.
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.
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.
- 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.
> 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?
but then AGPL is not the problem, CLA is, right?
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.
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.
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.
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.
Are you for or against the Affero?
Depending on the side your choose, could you explain a bit more on how and why Affero helps or does not help in the 1990s purpose of original 1990 license?
Depending on the side your choose, could you explain a bit more on how and why Affero helps or does not help in the 1990s purpose of original 1990 license?
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.
> 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.
Related to your quoted content, do you consider the Elastic License and Server Side Public License (SSPL) to be the 2020 updated version of the 1990 pragmatic idealism or do you consider them to be not similar in any way at all?
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.
Related to your understanding of licenses, do you consider the Elastic License and Server Side Public License (SSPL) to be the 2020 updated version of the 1990 pragmatic idealism or do you consider them to be not similar in any way at all?
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.