OpenProject – open-source project management software
openproject.org
openproject.org
I click on github.. it doesn't open github... had to look in the comments here. I find repo here... the front end is some ancient angular app with 3 year old security vulnerabilities.
I try to find some kind of demo of the product.. and end up in a sales funnel to pay 500$
As a first impression this does not look like a trustworthy opensomething .org product, even though it's probably fine.
Just my opinion
It sounds like they want to do a "community edition", so they could just do it from a .com, and set expectations appropriately.
If they instead wanted to have a community-developed open source project, but also sell derived/layered products, they might set up a community governance structure and home it on the .org, at arm's length from their .com where they do sales and other company-specific stuff.
(BTW, sympathy on the challenges of building a sustainable business on open source, especially given some of the poor taste we sometimes see from freeloading commercial competitors.)
TIL dot com is apparently a "commercial" site.
.gov for government,.edu for education, etc. Certainly I would not expect a purely commercial entity on a ".org"
https://en.wikipedia.org/wiki/Generic_top-level_domain
P.s. You're making me feel old :-)
Then they seemed to focus more on making money from registrations, than from the custodian aspect.
Then ICANN created an industry of middleperson (maybe because there shouldn't just be one rent-seeker, but competing ones), and also seemed to bless a market of landgrabbing squatters. (And much more recently, some ICANN-connected people seemed to be scheming to grab a popular TLD for themselves, like a PE firm.)
With most of the good and even bad domain names taken by squatters, there was demand for all sorts of new TLDs (which someone was happy to middleperson).
As well as the risky practice of building your company atop a 2-letter country code TLD, where there's a significant chance of a change in government policy would break a lot of your links, URLs embedded in software, email addresses, and Googlejuice. Or simply have you over a barrel with exorbitant renewal fees (or bribes).
(Historically, some of these ccTLDs were small islands, where there was one sysadmin person running the "ISP" for the island, including domain name authority, and the government didn't necessarily even know/understand.)
Only to techies. And I'd say only to those who were techies back in the 90's or earlier.
All the other people very likely have no clue why there are all these different TLDs. And for people outside the USA, UK and AU, .com Just means it's an English (as in language) website.
Only one of the security issues seems to be unfixed, the others all have patch versions.
- Where did you find a broken link to our GitHub account and repositories on openproject.org? Appreciate your help in case our page is not correct. - What 3 year old security vulnerabilities in our angular code part are you talking about? Would you mind sharing a link? - OpenProject is fully open source (GPL 3), not half. You can host it yourself. And if you prefer it, you can get hosted by us, which for many organizations is cheaper than doing the hosting themselves. - Regarding your doubts about our trustworthiness: Have you checked who is using OpenProject? Siemens, the German railway company Deutsche Bahn, the City of Cologne, Audi, Hyandai, MIT, Greenpeace... On GitHub we have 2.2k forks, and 8.5k stars.
Peace!
And yes, it is true that OpenProject is used as an alternative to Jira. Mainly for two reasons: OpenProject is made with data sovereignty in mind. And Atlassion pulled Jira's self hosted option off their shelves. And the other reason is pricing, I guess.
Their hosted options though, seem reasonably priced.
If the goal is to have <10 employees working on an open source project, then I think it's a completely different story, offering just cloud hosting with no extra features is within the realm of possibility. Keep in mind that while one sysadmin is not cheap, a company relying on multiple cloud-hosted open source tools will at some point find that one sysadmin very cheap in comparison. He'll even have time to do some other things as well. That might be a completely viable route for some "simple" open source project (Plausible and SeaTable immediately come to mind), but some open source projects are just aiming to be complex enough to need more than 10 people.
In summary, I personally believe everyone should be pragmatic enough to be fine with the "open core" model. Otherwise, there's no chance in hell we'd have so many cool, open sourced (to an extent), self-hosted tools at our disposal.
The pragmatism of self-hosting is key parts of the software will be missing and you may not get a comparable experience.
The issue is not charging. The issue is where key, and actually core, functionality is sitting on the paid side. The idea that "at some point" you hit a paywall is generally not true. It can border on crippleware, and might as well be shareware (still great to support small development teams).
Evolving licensing and revenue generation is key.
The reality is we wouldn't have the world we have today without open-source software, as in the totally free kind, and at some point it does need to be maintained, unless some of the few packages reach some sort of maturity.
Your point about sysadmins not being cheap is fair. I would offer a counter-balance and ask how many more things than need to be are made to be far more complex than they need to be. After all, open-source is also a place of learning, experimentation, and breakthrough, and technical debt.
Still, other projects get so much done with so little support. Restricted core features pretty much tunes out a lot of users to get over the value inertia. It's hard to call it open-source, when it's not quite open source anymore.
One license I've seen is requiring companies over a certain revenue or headcount to have to license. Even JIRA had some of it figured out with their lowest license offering, but for a ton of functionality)
AGPL is helping with some of this - the more projects evolve to partner (for example if someone wants to license the tech to be part of an unrelated project)
Maybe the product managers should be the development team.
It's far easier to financially support fully open source software even though it might not happen as much as it should. I've recently come across an excellent loom alternative in Screenity and the developer only has a few sponsors.
Packaging open source for supporting the development of the software can come in many forms.
Sorry for nitpicking, but this is the only thing you've said that I actually disagree with.
It is a hell of a fight to convince a company (or even worse, a non-profit) to pay for something that they could get for $0 by self-hosting. Symbolic, one-time gestures are possible to fight for, but a reocurring, significant amount is just not. If your open source project offers anything back in return for payment, it's a much easier sell to make. It doesn't have to be complicated or introduce a lot of overhead, it just has to be something, even it's like a very rarely relied on line of support or a logo on the homepage. Same goes for premium features, you just have to strike that right balance, which I believe we both fully agree on. Your tool has to be useful as a free, standalone product, at least up to a certain scale. I have my grudges about where that line gets drawn sometimes, but I can't hold a grudge about the exististence of such a line. It doesn't stop me from testing out your product.
It is of course a shame that we don't have to go through any of this for any fully proprietary product. It is what it is, it's just a question of whether it's worth the per-user price. There are tons of companies out there that have used an open source product for years, never paid a single dime, and then switched to a proprietary, very expensive solution.
There's also a lot of us disgruntled sysadmin/DevOps/SRE people along the way, but our powers are limited. Make it a little bit easier for us by charging for something we can't otherwise get from your free version. It's mutually beneficial for everyone involved: we do our best to give you some money (in return for something), sometimes we're succesful, and then that success usually contributes back to the fully open sourced version being better in some ways.
Individual donations are fine, I do them as well (less consistently than I'd like to; far from nothing), but convincing just one single company to pay up beats the hell out of 100 individuals. It's a fixed, agreed upon sum, usually guaranteed for a period of time by some type of a contract. There's also only one processing fee involved. It is always gonna be difficult to find that first one, but if you pull it off, the odds of your open source project "succeeding" (however you define success) increases dramatically.
- The linux kernel
- Languages (Rust, Python)
- Airflow
- Libre Office
Either way, I think the important thing is knowing why you want something to be open source (do you want to self host? Own your data? Fix bugs? Do you have doubts that the developing company will last long?) Some of those will work great with an open core model, others won't. I think if Linux was "open core" it wouldn't get used at all, that's a lot less true of something like libre office.
To be even more specific: I was responsible for maintaining three OpenProject installations in three completely different places. One is a small non-profit that couldn't realistically afford anything else, one is a cheap and very poorly-managed for-profit company, and one is a much larger non-profit that ultimately ended up paying for some "better" proprietary solution. The only things I could think of that those three places have in common are: I worked there, and OpenProject was used to some extent, even if only briefly. And it was never because of me! Other people have made that decision, but it was my responsibility to maintain it.
That's why I'm so opinionated in this thread.
Imagine if Linux was Open Core, and we were supposed to be thankful for even that, and pay the Linux foundation for Linux Pro if we needed a commercial grade kernel. That'd be like having to buy AT&T Unix again, right? There would be a fork in order, right? Too much has been sacrificed to accept a partly non free kernel.
But suddenly this idea comes along that the project needs to support a company on its back. And suddenly the company only cares about delivering the bare minimum open source than is necessary to annoy clients into the Enterprise version. The open product chokes, and a real open competitor appears. We migrate from gitlab to gitea, from MySQL to MariaDB, from redis to valkey, and so on.
Open source is more important than your or my company. If either open source or our company has to die, it's far better to elect for our company to die, rather than threaten open source. Likewise, any company that threatens open source with the open core model will eventually fail or fall behind genuine open source competitors.
If you build a company on open source, why not let it be fully free, selling services, support, and consulting? I think the days of Open-Washing via Open Core are coming to an end. The last 15 years have seen it betray so many previously lively communities. I strongly believe that in the future, open projects will have to be fully open to merit credit, or the community will immediately recognize them as bad actors, and standardize on a truly open alternative.
Of course there's projects in open source where it's only free if your time is worthless. This means lots of manual figuring it out as some sort of badge of accomplishment, intentional, or not.
Then you move towards more user friendly software, and more and more towards easy to install.
There is a type of open source that is a funded startup, where open source is used as a way to attract paying customers, and not really be originating as open source. There's been lots about this out there.
The devil is pretty simple to see. if a new project reaches the point of adoption and quickly moves or puts core features into a paid tier, it was meant to use free community attention and labour and not give back more labour. At this point a lot of meaningful forks can occur.
Free vs paid open source is the major difference that I'm speaking from. There was a time, not too long ago where this wasn't the norm. I agree large corporations should pay for and support open source, because with out it much of what we have and use today wouldn't be as possible, as quickly.
Here is a (biased) overview on how the product compares to RedMine: https://www.openproject.org/blog/openproject-an-alternative-...
Maybe it's just me :) overall it looks like quite the overhaul from its redmine roots. A lot of what I had to hunt for in paid redmine plug-ins years ago is just a core feature in OpenProject.
I would interpret "issue" as more of a general "thing that needs doing" whereas work package has a fairly specific meaning. I wouldn't want to use the phrase work packages as items in a bug tracker, for example.
See:
- https://prince2.wiki/management-products/work-package/ - https://www.nasa.gov/wp-content/uploads/2023/08/nasa-work-br... (pdf)
> A lot of what I had to hunt for in paid redmine plug-ins years ago is just a core feature in OpenProject.
[1] https://www.abacusthemes.com/ [2] https://www.redmineup.com/pages/plugins
Plane: https://plane.so/
Kanboard: https://kanboard.org/
Taiga: https://taiga.io/
Redmine (which OpenProject is a fork of): https://www.redmine.org/
Teambox: https://www.teambox.com/
GitLab (more than just issues): https://about.gitlab.com/
Seems to be a rails app on top of Postgres.
Into the trash it goes. Even if I was a big corporation, I wouldn't depend on something that was only made to make money off of it to manage anything.
Think of it as a higher level, more encompassing approach to project management that can include both the technical and non-technical work.
You can create hierarchies of tasks, connect them, assign them, and they are not only for software development like GitHub.
It can also tie in with Gitlab/Github
It's worth watching a Youtube video or two to see if anything resonates than asking strangers blindly on the internet to give us the perfect explanation :)
For a small project it's probably overkill, but when you need to manage a large number of tasks and/or a large number of workers (including product managers, QA, etc.) you need more than a simple text box with some labels.
Project management tools are just a necessary skill even for non-devs, which leaves any large enough project with only two options:
1. Have the devs and non-devs use completely different systems.
2. Have both use the exact same tool, even if that absolutely sucks for the devs.
The second one is bad, the first one is worse. It by definition creates an unnecessary complication in the flow of information, requiring serious effort to overcome. That's why most of us have horror stories about Jira, Asana, and the likes. The hatred of that one particular tool we happen to be using right now unites us all. Whichever tool you're currently using is always the worst one, right until the moment you're forced into using a different one.
So, you as an individual might want to put up with one of these horrible options you're already familiar with, or you might use something you actually enjoy. But beware: if you go down the more enjoyable path, you are perpetually gonna be reminded it's not the "real deal". GitHub can't do everything a proper tool can, and you're gonna miss having those "advanced" options at some point, even if you hate to admit that to yourself.
Then again, I might just be projecting.