Looks pretty basic but somehow complete. The first impression is good. Here's some criticism:
The first thing I look for in a issue tracker is the screen estate to write the task. I understand that some people write a list of issues in the form of short blurbs and iterate on them afterwards, but it always feels frustrating to me to having to write the title in a modal window, save and then open the issue again to be able to see a larger textarea for the description. I also see it as discouraging for people to write better descriptions for the issues they open.
The keyboard navigation is probably not complete (press P to create a project, you would still need the mouse to focus the textbox and to save the project)
On my computer it started in Dark Mode, and the experience overall was quite a bit disorientating. Also no light/mode switch icon in the header.
It is not clear to the user that you can/should use markdown.
I don't really know that you need a light/dark mode switch. It should follow your preferences. I see dark mode websites all the time, because my desktop is set to dark mode. On my Windows machine I see the same websites with the light-mode, because I did not bother to figure out how to set Windows to dark-mode.
[EDIT: The Plane App ignores my preferences].
The era for security and in particular identity and auth management to be pay-to-play is long over and I appreciate when projects and businesses are honest about that.
You seem to be advocating for SSO for personal use too, to which I say: hell no. I don't even use the same email address between different sites. Why should I give every site I log in to a freebie for cross-site tracking?
I was speaking primarily from a business perspective, in particular one where I make technical decisions for mine and other (client) businesses.
Experience has taught me that SMBs benefit greatly from SSO. They’re also simply the least likely to have the talent around to implement it well and reliably. So while you can use the SSO tax to drive revenue, you’re just moving the burden of account management to individual users and admins of small teams. As a long-time provider to small teams I can tell you how much they really hate dealing with that overhead when they probably already have a SAML and/or OIDC IdP service included with their MS365 or Google Workspace tenant.
So as a result, I select away from those offerings if there are comparable alternatives, and there almost always are.
I am not advocating for the use of social IdP (“Sign in with [Apple|Microsoft|Google|etc]”) for anything. I really dislike those as well, to the point that I actively select against services that only support signing in with a third party that I can’t control. I was specifically talking about SSO as it’s traditionally interpreted: SAML, OIDC, LDAP, etc that you control.
"SSO refers to a SaaS or similar vendor allowing a business client to manage user accounts via the client’s own identity provider, without having to rely on the vendor to provide strong authentication with audit logs, and with the ability to create and delete user accounts centrally, for all users, across all software in use by that client."
It’s certainly not a SaaS-centric thing. SSO has been around once before we used it widely with HTTP.
I would also argue that the last part conflates SSO and SCIM. Usually these are kept as distinct features, even if compatible.
Cannot be closed source unless the maintainer dual licenses and stops making OS (assuming a single maintainer or group that all agree, or that other contributors have signed a relevant copyright waiver).
(though what has already been released can't be retracted)
In this case, it looks like Plane is not requiring copyright transfers. So that cuts off the practicality of them ever re-licensing their software (commercially or otherwise). That's a good thing as it means it is indeed not likely the license will ever change. The bad thing is that it would be hard to build a company around this project. The AGPLv3 is just very strict about having to open source any and all bundled features and imposes a lot of restrictions and requirements.
LOL, at least they are honest about companies doing waterfall style planning being their target audience.
You could probably do without one at all even.
My impression was that this level of transparency was extremely appreciated by customers, even in cases where bug fixes were marked as "won't do", usually with a workaround of some kind. This in itself also becomes an invaluable knowledge base over time, not to mention all the other benefits you get from support and engineering tracking their work in the same application.
But of course, like all good things it didn't last, because the company was bought by some other company that thought it was absolutely insane to publicly admit that your software had bugs.
my team just merged with another, larger team.
before this merge we operated off only github issues and never had problems with it
now we have length jira planning sessions, new meetings every 2-3 weeks on updated jira expectations, and a whole group of people whose job it is to track our jira usage and let us know if we aren't using it correctly / meeting standards
under one system we always finished work ahead of time and could actively pursue more projects
under one we are constantly behind the "estimate" for our assigned work
care to guess which is which?
Planning schmanning!
Or maybe just to reach someone who never used bugzilla and doesn't realize it's light-years better than jira or rally.
Bugzilla had a "this is how it's done, and that it is" attitude to bug tracking workflow - it wasn't configureable. As such, it couldn't be perverted into a dozen gates with different approvals needed for each gated step.
It's really easy to copy Bugzilla's structure into Jira. It is very difficult to keep management from changing it into something else in Jira.
Not in the sense of the feature set, there's only so many things you can do with an issue tracker and a kanban board, but in the sense of actual visual design (fonts, text sizes, etc.)
What is the story here? I'm just curious (and bored) :).
This has the interesting side effect that the word solfege (sol-fa) makes little sense.
What I'd love to see, is to be able to assign one person as the one "responsible" and then assign others ad-hoc when/if they work on-, review-, discuss, or co-author it.
Some software allows multiple assignees, but as the ancient management-saying goes: if everyone is responsible, no-one is. So i'd still love to have one person assigned with a special role or label.
My previous company used Phabricator and you only assigned yourself a task when you actually started working on it. It meant anyone could work on anything - much more agile and much much better knowledge spreading and teamwork.
But I understand where my current company is coming from. You want a "person who is responsible for making sure this eventually gets done" field and a "person who is currently working on this" field.
So each ticket gets a Primary Developer, Primary SME, etc, but might get assigned to some one else to do one small bit of work (e.g., it'll get assigned to a different developer for code review, but whoever's listed as the Primary Developer is still responsible for it).
Having to rely on comments or assignment history to uncover that information is a bad experience.
Shared responsibility is called collaboration.
Subtasks kinda helps in Jira
There’s currency in this type of knock off. Find a well executed closed source app, clone as open source, pick an alternative pitch “the Jira killer”, then raise YC because open core is the fashionable argument.
Related: I would love to see an open source confluence alternative as well, as for issues there are many (more or less capable) options to choose from.
Deduplication guidance, reports on untouched content…I don’t know how to fix this, but someone surely can solve it.
I'm really impressed by the product. Seems to be a good Confluence alternative.
No, AGPL means that if you're using it to provide a network service you must offer the source *to the users*, but not necessarily share it with the world as a whole.
If you use it internally at a company, your modified source must be made available to your internal users. It is not required to be shared with the upstream project or the world as a whole. This is the same as any other GPL software, just with the AGPL network interaction provision.
The only time AGPL requires sharing your modifications with the world is if you're using the AGPL code to provide services to the world.
> I wonder if these licenses are hurting the adoption of OSS alternatives for enterprise software
There are definitely a lot of enterprises that are paranoid about even using anything GPL related, mostly without good reason.
If an organization that doesn't want to even consider sharing their modifications to code they're getting for free avoids using (A)GPL software as a result I think most developers who choose those licenses would say everything is working as intended.
If you run Jira, Confluence and Bitbucket, the level of integration you can achieve is pretty unmatched. The cost: You need to buy the data center edition, on-prem is required to get any sensible level of performance, and you need Atlassian experts on staff.
In the few different companies of different sizes that I worked, I never saw a Jira that did not become a hot mess until people start new projects or new boards when they can't bear anymore.
I find it also extremely difficult to find anything. Like you know that an issue exist but search will not help you find it easily. Very often I have to go to Gmail to search in notifications to find back the link to an issue.
In our company our CIO declared everything should be agile. So now we log our hours in Jira. That's it :P supposedly that makes us agile or something.
Perhaps you've been fortunate enough to be employed where these things are managed better than my hypothetical scenario above, but my experience that is the exception, not the rule, so it's not surprising that people can become fatigued.
There's no obligation to propose a better solution when saying something sucks.
It can look a little bit rough, and sure there could be lot of improvement. But it favored efficiency against eye candy design.
It is very easy to have things organized the old way. Having projects, recursive sub-projects.
You can look at your issues at the sub sub project level or at a more global level.
You can easily have list with all the variable that matters. That you can order easily how you need: Who's the rapporter? Who's the dev? Who's assigned to? What is the state? When was the issue discovered? In which version? Fixed with which milestone?
It is very slick, I did not feel a latency like in Jira, the screen is not filled with useless crux, only what matters fills the screen. In a few clicks I was always able to find what I was looking for, set and identify all the affected versions and which one got the fixes.
Most of the times when I read some post about Jira alternatives is that they completely ignore this topic.
