@Ali I think that’s a better idea. I did start recording anyway so that I could show things more deeply but realised that an official video that has actual data would represent things better.
Here is the video I recommend for a quick overview:
@gabor @tikr Sorry for missing your pings.
I’m putting a task into my next sprint to prepare rough estimates for the transition to Huly.
That sounds good, thanks @kshitij 
Hi all,
I’m here to resurrect this thread. Unfortunately, it looks like Huly is not going to pan out like we thought. The latest release now requires the addition of more than one proprietary service, and they are dropping support for some critical open source components (such as the database). My questions about this have been met with silence in their Slack.
I think it’s time to revisit some of the previous options we looked into in this thread. Since we left it, Tenzu has made a great deal of progress, and they do seem to have both a commitment to free software and a consistent history of delivering it while maintaining solvency (like us). It does appear to have some community.
They are still a ways off from where we need to be in order to move to them, but I think we should seriously consider just what we would need to add and if we’d be better of closing that gap than trying to migrate to any other system that is either not as far along or else isn’t keeping to our open source values here.
Here are some things I have noticed appear to be missing at present:
Meanwhile, it also appears that @gabor 's project Elemo has continued on as well. So we might consider that too, though my attempts to use it don’t seem to indicate it is quite as far along. It’s my understanding that the backend supports much more than the frontend currently can manage, but I’ll let him comment on where it’s at right now.
This is sad to hear but at least it happened while we hadn’t invested too much into it.
I know it is no one’s favorite, but I think redmine is definitely worth another look.
I just spent a bit of time spinning it up locally using a premade docker compose file, and while the UI does have much to be desired, the project’s source control remains on SVN, and for some reason it has basically no default data which I might expect it to have (I had to set up a lot of unobvious data about workflows and statuses before I was allowed to even create an issue), it does look like it would work.
There also appear to be open source plugins available that may be enough to cover our remaining issues. One thing I’m unsure about is associating time logs with accounts, but I’m sure there’s something we could come up with there, considering that there’s already time tracking invented, and there’s a custom field functionality. The missing bit is custom enumerations, by the look of it.
So I’m coming around to Redmine, despite my hesitations about it. I’d be willing to start on building out redmine to experiment with instead of continuing to work on Huly.
Oh, this is a bummer; especially that they neglected you on Slack several times.
Meanwhile, it also appears that
gabor's project Elemo has continued on as well. […] It’s my understanding that the backend supports much more than the frontend currently can manage, but I’ll let him comment on where it’s at right now.
Your observation is correct. The project has been receiving continuous contributions from collaborators, and the backend already supports a wider range of features than the frontend. Since its discovery, one of the most significant developments has been a complete frontend rewrite. Given that most collaborators are frontend developers, this aligns well with the current focus and progress of the project.
However, as I recall, there were some concerns related to all Tenzu, Redmine, and Elemo.
I was hoping that Huly will be good for us after the initial promising start.
Re: Redmine
Do we really want to set the bar that low?
I’m wary of adopting a tool that, based on what I’ve seen and read so far, seems to be stuck in the early 2000s. Not just in terms of its UI, but apparently also in terms of developer and operator experience 
If this were a tool we’d only use occasionally, that would be one thing – but here we’re talking about a system that’s central to the way we organize and manage work, and that we will be using and interacting with countless times every day.
From my perspective, such a system should be nice to look at and work with at every level/for every type of user (= regular users, developers, and operators alike). Right now I’m not sure if Redmine is that kind of system.
This isn’t necessarily specific to Redmine, but one thing I want to highlight is that we’ll need more than just the basic ability to associate time logs with accounts. A lot of budget tracking, accounting, and sustainability-related work depends on the ability to generate various types of reports for different entities, e.g. users, accounts, projects, and even results from custom JQL filters.
@tikr I’m afraid we’ve set the bar too high.
I think we are searching for a unicorn at this point. We want a system that has all the major features of Jira that we want, has an active community, and has a beautiful modern user interface while not only being open source but also not even having any proprietary dependencies or an open core model.
After a lot of looking, I have to say such a system may not exist. What we need to do now is find things we’re willing to compromise on.
With Redmine we compromise on the UI. It is definitely ancient-looking, but there are more modern-looking skins available and a vast plugin ecosystem. It’s written in Ruby, which isn’t ideal for us. It’s older than GitHub and still actively maintained. We can improve the UI, and the out-of-the-box experience.
With Elemo we compromise on the community and history. It is a new project, with missing features, written in Go so we’d need to do a lot of work ourselves. That said, I do think that if there is demand out there that isn’t being met, it’s a good opportunity to do things ourselves.
With Huly, we’re locking ourselves into a platform that’s making concerning decisions, such as the usage of proprietary tech and their move towards blockchains. However, it does have most, if not all, of the features we want and more.
With Tenzu, it’s a project in the middle of a rewrite that has a lot of missing features. However, it is written in a language more of us are familiar with.
My personal feeling is that Tenzu or Elemo are a better direction. Tenzu because it’s written in Python, they have an active community and even participated productively in this discussion itself. Elemo because we can make it into exactly what we need.
With that said, if we want to take ownership of an codebase, we can also consider simply forking an existing project and updating it in the direction we want. This could be an open-core project like Plane, Odoo, Tuleap etc.
As @kshitij mentioned, we might be looking for a bit of a unicorn here 
I agree that the tool we pick is important for our workflow @tikr so it would be nice to have something that makes the experience pleasant.
@kshitij Maybe we can run a quick poll to get feedback on our options? It would help to know the time, resources, and tradeoffs of each option.
My only hesitation with Elemo is the time investment, especially after everything we went through with Listaflow. It would be great to respond to a demand that isn’t being met, but are we sure there are other companies with similar needs to ours? And could we get funding to make it viable?
If we need to compromise on something, I would personally lean toward using Plane until one of the truly open source options (ideally Elemo) meets our requirements. The downside is that it’s open core, not fully open source, so we wouldn’t be supporting a proper open source project/community. But I believe it otherwise supports all the features we need, and it seems like the nicest option in terms of features and UX. Whatever tool we pick is so core to our daily work that it needs to be excellent, and I think it’s better to compromise on something like open core than to pick a tool that can’t handle our core workflows.
And all the time that we save from picking a ready-to-use solution (with a Jira importer no less) can go toward more useful stuff like Open edX contributions or Problem Builder v2.
This is also my concern. I still think there probably are some companies that could have used Listaflow (I’m planning to deploy it on my own home Kube cluster for my own needs), but it would have taken much more effort than we were willing to put into it in order to hit product market fit. Building products means taking a ton of work on contingency unless we can find funding from the start, and the community building is the most difficult part of the equation and requires both a great deal of effort and a lot of focused marketing effort– much more than we’re used to spending.
The developer in me would LOVE to be on the ground floor of a new product project. They’re always fun. The pragmatist/business minded person in me is not excited at the prospect.
Here’s the thing, though. If we’re committed to switching to a fully open-source solution, we’re going to have to do some impractical stuff since there isn’t a pre-existing solution that works for us. That might mean shoring up the yellowing walls of Redmine. It might mean giving a big effort boost to Tenzu or Elemo on heavy contingency. It might mean forking another project to add on missing proprietary features, or extending an open core solution to have the missing features we need.
We could also take the easy way out and migrate to Atlassian’s cloud service and rely on GDPR or similar laws to be available and enforcible at the time of migration, conceding defeat until something they do becomes so intolerable that our hand is forced. But we don’t know what situation we’ll be in when that day comes. We can just expect it will come because the move to their cloud service away from the individual installs was already intolerable enough that we’ve resisted migrating.
This is probably the most practical solution if we’re willing to compromise. We would need to either fork over the cash for the non-open extensions we need until the fully open ones are ready, or we would need to develop fully open extensions, putting us on bad footing when working with upstream.
Here’s my concerns with going for open core:
So if we take this route, I would really like to see us make at least some carve-out time for assisting one of these projects to help them along and guide them in the direction we want, like carving out some dev/product time we’re willing to allocate to help them get toward the finish line. Otherwise we risk being in the same boat again in a few years.
+1 - I have used redmine in the past, and I wouldn’t be looking forward going back to that.
Could we do another round of discovery & reviews, taking into account what we know now, and updating the evaluations and comparisons accordingly?
In this new round of discovery/review, could we include the option of starting a community fork of Huly, which keeps (or adds) the options we want? That would come with significant maintenance, but maybe there are others in the Huly community who would do it with us? If the project is really that close to what we need, and the next best alternative is redmine (!!), we can’t be the only ones regretting the sudden change of direction of the Huly project?
@antoviaque Would it not be better to focus on something like Tenzu if we are willing to take more ownership? It is developed in Python and Django so we’d be up and running a lot faster. It should have more of a community than Huly, which is still quite new. We would have more work to do to bring it up to our requirements, but we’d have to put less effort in learning. Additionally, we’ll avoid anything as hostile as forking a codebase.
Additionally, if we are open to forking, we could also just fork any existing open-core tool and add back the extension features into the core as an alternative, similar to what Forgejo did with Gitea.
@kshitij We can definitely discuss those options - this is part of why I requested a follow-up discovery with an updated document. We need to revisit the overall approach probably, and have time to review and discuss these elements, after you have had time to reconsider our options in the current context.
Meant to comment on this earlier, but wanted to add this bit of thought to the pile, discovery or otherwise:
After having worked with the Huly codebase to try to understand it and make sense of a lot of the design choices, I’m not excited at this prospect. Huly is an everything app that just happens to have enough everything to hit most of our needs, plus a ton of stuff we really do not need, and this massively generalizable feature of it makes it a complete pain in the ass to work with and understand.
There’s a lot of inventing from scratch going on, it’s almost entirely undocumented, and it has something like 20 separate services.
It wouldn’t just be preferable to get other community members-- it would be required. Forking in this way, I would expect, would require having already established a reputation in the community and convincing people to join us. We are wholly unknown there.
If we were to fork an open core project that was more oriented around being a Jira alternative specifically, that would certainly be preferable. In that case even if we weren’t able to convince many people to join us, we could still function, and bring more in over time. With Huly the maintenance burden would be too overwhelming to start, and too much of their core services are depending on non-open things, such that we WILL have significant upstream drift.
This is partly why I wanted to avoid some of the similar tools like Grist and NocoDb, which could potentially be configured to do most of the stuff Jira does but are overly flexible.
@antoviaque I will add a discovery to the next sprint to look into:
FYI. If someone else wants to pick up the second iteration of this discovery, I am happy to pass it along and review it instead.
@kshitij Did you get any takers? Just to make sure we don’t lose the thread on this.
@antoviaque I don’t think there any one else interested in taking this up. I’ve created a timeboxed ticket and started initial work. Since we’re looking into more actively contributing / forking / maining a project I think I’d need to take a deeper look on the code side as well.
