Getting the wrong vibes from the dark patterns on this site.
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.
Agreed. In traditional terms, they're using a .org domain as a .com. The old rules aren't enforced, but they still hold some meaning.
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.)
Yep, earlier on, the non-country-code ones had rules about who could use them, and the registrar for some of those was expected to be a custodian.
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.)
> The old rules aren't enforced, but they still hold some meaning.
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.
- 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.
I mean, admittedly you have to scroll down to the second half of the (long) page, but the "Code repository on Github" link goes straight to the github project page for me...
Only one of the security issues seems to be unfixed, the others all have patch versions.
This project was picked up (and forked) by Rosatom for its internal Jira replacement after they got cut off from Jira in spring of 2022. No idea how many changes they introduced, but I guess OpenProject should be powerful enough (or at least provide a powerful enough base to build upon) to handle giant projects at their scale. The fork is not publicly accessible, although they do conform to the GPL and provide the source code to their clients.
Thank you for the intersting link. If you checkout our GitHub repository you see that there are 2.2k forks. We don't keep track on all of them.
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.
Project management actually seems like a good candidate for open-source. It seems like companies often need customizations. I could imagine forks for different industries.
The devil in such case is in details. Is Open Source version actually useful or is it really there just for marketing purpose ? I think this is where how large portion of users are running free vs paid version is a good indication.
It's probably worth first thinking about your first year of interaction with Open Source, and if the world might have been different before you first experienced it.
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.
I think every open source projects that has ever aimed to have >10 employees has taken that same route at some point: GitLab, Matomo, WordPress, Redis, MySQL, nginx, HAProxy... all incredibly useful for in most use cases completely free, but if you try to really rely on them (on a large enough scale), you will hit that paywall at some point and feel forced to pay up.
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.
I agree with your main point, but I can't resist pointing out some huge exceptions since there are some mammoth fully open projects like:
- 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.
All completely valid counter-arguments. In my defence my perspective is very narrow towards only self-hostable open source tools. Like the types you might wanna self-host in a company anywhere between 10 and 200 employees. I don't have any knowledge of, say, open source libraries and how they operate, and the same applies to all of the exceptions you've listed except LibreOffice.
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.
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.
> It's far easier to financially support fully open source software even though it might not happen as much as it should.
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.
I think you sell short the promise of true open source, which gives us much more than what open core can offer, in a more sustainable way. I find it endearing that you in effect attack purists for not being thankful for unusable crapheaps like gitlab. Let's admit those projects were all relevant a decade ago , but have all become very stagnant and painful to use our maintain because of their open core fragmentation and technical debt in the open product. I know they have been replaced in my own usage and orgs.
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.
Reading this, I had a little laugh after reading the entire spiel about increasing intuitivness and the first point is renaming issues (universally understood) to "work packages" (what?).
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.
"Work package" is a pretty universal term in non-software project management, though a single WP could contain multiple todo items. I'm not sure whether it was coined by one of the frameworks like PRINCE2, but a lot of large/governmental systems use it (certainly the UK/Innovate, NASA and ESA, etc).
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.
It's been a long time, but looking at my email invoices it was Abacus[1] for modernizing the frontend and a bunch of plugins from redmineup[2] like Agile and Resource, which appear to be default OpenProject features ("Board" & "Planner").
I agree that the term "work packages" does not always fit. "Issues" doesn't neither. An "Epic" is not a an issue, in my opinion. I am curious which term you had on your mind.
It's interesting that when they forked in 2011 they switched from a RoR app to an SPA (angularjs then angular) + REST api to be able to get better UI interactivity. Now it's 2024 and after we've had SSR and hydration, JS frameworks are moving to even tighter integration between client and server (for example React Server components).
Yes, we are moving away from the SPA approach. If you follow our latest feature developments you will see that we now try to adopt the HOTwire approach in combination with GitHub's Primer ViewComponents. And it is fun!
I have been building this on and off for a number of years. Mostly focused on the document management side of things: https://github.com/bgroff/kala-app
I typically prefer the simplicity of GitHub issues, mixed with Markdown documentation in the source tree. What are some advantages of using a product like OpenProject?
Ability to organize issues in various ways, more powerful search and filtering capabilities, easier to track work done and plan work that needs to be done, etc.
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.
It's much better suited at project management than Github.
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 :)
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.
Some people manage projects that aren't software at all. Git has little utility for construction documents, and big construction design projects may involve interdisciplinary teams of dozens of people of widely varying cost and availability.
The BIM addon entails quite some features:
- It allows you to share your construction 3D models as IFC models (a standard of openBIM) with the rest of your team. Everyone on a project suddenly has access without having to pay crazy license fees to Autodesk etc. You simply view the models right in the browser.
- Everyone can create and comment on issues within the 3D models. Issues can be imported and exported via the BCF format, another openBIM standard.
- There is add-in for Autodesk Revit, so that you can fix issues reported in OpenProject browser based IFC viewer straight away in the 3D model authoring tool.
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