intheleantime

Building AI coding tools, there are two common options.

The AI suggests code and you run it. Or the AI runs code on your actual machine. We decided to go with the third option: The AI gets its own computer.

Sandboxed Linux workspaces that CoChat LLMs spin up on demand. It Write code, installs dependencies, runs tests and start servers.

We are now running an automation that gets triggered every time an error is logged in Grafana Labs, the agent then spins up the workspace to verify and fix the issue before creating a PR and Issue on GitHub. If it had already addressed the issue previously it will just track occurrences.

We get notified on Slack.

There is something to be said about that, I agree. For that reason you can turn off memory inside a chat thread and also create temporary ones that do not use memory.

Thank you and great question. Right now, feedback is qualitative only. (Surveys, feedback buttons, controlled user tests). We are trying to build AI evaluators but they suffer from the same problem when trying to evaluate whether the “right” memory was pulled.

Still trying to find a good solution here.

lol the I stands for “I think I know everything”

Thanks for the feedback! I agree with the general sentiment. At the same time we want to target companies that are aware of their neurodiverse workforce.

Thanks! There is so much more to come!

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.

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.

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.

PS I forgot to mention that we have Sentry profiling. Full Application load (php side) P95 is 120.9ms and P99 is 634.11ms

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.

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.

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.

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

"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.

Thank you for the feedback! Don't hear a lot of people say anything positive about AGPL these days... :)

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)

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.

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.

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.

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.

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?

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.

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.

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?

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.

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.