Hacker News new | past | comments | ask | show | jobs | submit login
Apache OpenMeetings – Video chat, messaging, white board, doc editing and more (apache.org)
333 points by pabs3 57 days ago | hide | past | favorite | 119 comments

It's a bit sad, that even open source projects that are this big, don't have any cohesion of UI.

The whole things looks like as if every developer that worked on it just decided to randomly place a button for their feature somewhere. Well... probably that's what happened.

Unfortunately, until most OSS looks like this, it'll be very hard for them to gain ground over the commercial alternatives.

There are three better open source alternative to this: Nextcloud, Matrix/Element and BigBlueButton. All three have a way better interface than this.

Nextcloud is more oriented towards storing files but recently gained tons of social features (video chat, messaging) and has since some time already document editing with LibreOffice online and a build in document editor. There are also tons of other features like LDAP integration, calendars, ...

Matrix/Element is oriented towards messaging between organizations and inside organizations. Element also support video chat and contains an Etherpad integration for document editing.

BigBlueButton is not great for messaging but is excellent for video chatting. It scale a lot better for big rooms than Nextcloud and Matrix because it doesn't use Jitst and WebRTC, but it doesn't include any document editing.

So yeah OpenMeetings is not really a flagship open source software and I'm wondering how it ended up in the front page of HN.

> BigBlueButton [...] doesn't use Jitst and WebRTC, but it doesn't include any document editing.

With a few others, I struggled through setting up a "distributed" (i.e. not all on a single machine) BBB deployment early in the pandemic, back when the documentation and community explosion hadn't quite happened. Such a deployment is nonstandard and you're left to your own devices to make it work, albeit with some decent architectural documentation so that you can work out which component needs to run where.

BBB does rely on WebRTC exclusively for its media. The so-called 'HTML5' client is in-browser. There is a Flash-based client that's officially deprecated, and they're slowly stripping out support for it.

There is also some optional Etherpad integration, so that you can collaborate on in-meeting notes that are made available afterwards.

BBB's biggest problem right now is that the Debian packaging, which is the only official way of deploying the software, is not open source. It's also really messy -- some stuff goes into /usr/local, some into /opt, with a fair deal of leftover crud that isn't used any more like the Flash client.

This is an unintentional situation, but the maintainers have deprioritised making the software truly "open source" (IMO) in favour of bugfixes and features.

I don't think this situation meets the GPL it's licensed under, regardless of whether you would qualify this as "open source" or not.

I am the Product Manager for BigBlueButton. We have been building out the project for the past 12 years to focus on one market: online learning.

With Covid-19, it has been a pretty intense 2020 for the BigBlueButton project In 2020, we’ve seen some large deployments of BigBlueButton (100's of servers serving thousands of simultaneous meetings). Such deployments do not deploy a single large core machine; rather, they deploy many individual BigBlueButton servers in a pool (see https://github.com/blindsidenetworks/scalelite). We don't have BigBlueButton structured where you can split across the components on separate servers: the recommended deployment is each server is a self-contained BigBlueButton installation.

There is a large community of users around the world using BigBlueButton. We, the core developers, have been focused on ensuring that BigBlueButton is solid and scales horizontally. We released 2.2.0 on March 29, 2020 and the current release, as of Nov 11, 2020, is 2.2.29. Those 29 iterations reflect a strong desire by the core development team to respond quickly to the demand and make BigBlueButton the best possible solution for virtual classrooms.

Regarding the packaging, behind the scenes there are a bunch of scripts that I wrote using fpm to build the packages, and it's all non-standard, has grown organically over the years, and needs to be updated.

We had planned to clean up the packaging in 2020 and include it in the core it so others can build and build upon it, but all that got put aside when Covid-19 hit and there was so much demand for the software. Instead, we focused all our development resources on improving the system for end users (security, stability, usability, and features).

We are looking forward to providing standard Debian packaging scripts for BigBlueButton in 2021, alongside making continuous improvements to BigBlueButton.

Our goal remains to make BigBlueButton the best virtual classroom system for online learning.

Regards,... Fred

Hi--- I tried BBB for the first time today, --- not deploying my own server, but trying the demo online.

When I click 'start', I'm taken to https://demo2.bigbluebutton.org/html5client/join?sessionToke... which is a 404 Not Found page from nginx.

We use the demo servers (which have a lot of load) to test the latest builds. Try it now.

Any particular reason you don't include Jitsi Meet? (As that tends to be the first one mentioned)

I might be very wrong but I recall a required dependency of jitsi meet not being open source. This was maybe 3 years ago

I'm not familiar with BigBlueButton, but Nextcloud and Element both have a real (for profit?) company backing them, and they have full time employees working there. They're even hiring, with 7 and 8 job openings ATM.

BigBlueButton is largely led by Blindside Networks -- they also oversee the holding of the BigBlueButton trademark, logomark, etc.

Blindside's commercial element is to to consult on educational deployment of the software (which is its intended use).

Considering how much my university(about 3k students) seems to struggle with their BigBlueButton install, I wonder if it's really that hard to scale.

Voice, video drop out all the time, loading takes ages, recordings only process 50% of the time - and they say that they upgraded the machine it runs on three times with 80 cores and 500GB RAM. Especially when the lecturer insists on using a document camera, but the bitrate of the video is so small that you can't make out anything.

Really not that pleasant, especially in a situation where you need to depend on it for every event.

Several of those issues suggest insufficient bandwidth. The others suggest that there should be more than one BBB server, not one gigantic BBB server.

I think parent was saying the more than one BBB servers were upgraded to more than one gigantic BBB servers

It’s a uni so they probably adopted the throw-ideas-at-the-wall-until-it-sticks approach

Yeah, as far as I know they run 5 machines with these specs for the actual conferences now - still encountering these issues and no end of covid in sight for the near future, so I hope that they can figure it out.

Is there a single Java application with a good UI? Apache is fixated on Java, and Java seems to only attract a certain kind of developer. Even Java web applications, which aren't constrained by available UI toolkits, tend to look like they were written in Java (for example, all the AWS UIs). I think the language fails to attract design/UI/UX people.

The good news is that there's development in this space! https://github.com/jetbrains/skija

> Existing offerings are: Graphics2D from AWT, GraphicsContext from JavaFX. They are good, but underwhelming.

> Enter Skia. Skia has a proven track record of industrial-scale project relying on it for all things graphics: Google Chrome, Android, Flutter, Firefox Canvas, Xamarin, LibreOffice.

JetBrains IDEs, although I'm sure some would disagree with me there

In my opinion Java makes it really hard to create beautiful UIs without spending much time on it.

I also agree that Java attracts a certain kind of developer.

I always found jdownloader to be quite beautiful. Way before youtube-dl was a thing, jdownloader was there to the rescue.

No need to talk about jdownloader in past tense. It is still actively developed and I prefer it over youtube-dl most of the time, because it is way faster due to use of multiple connections.

I feel like this is a problem I've noticed with Apache projects in particular. I've used plenty of open source software with reasonably cohesive UI.

Exactly. It would be amazing to have some of the many incredible UX/UI designers out there help with open source projects like these. So many potential adopters are lost just because of the interface, no matter how awesome the software is.

I feel like that’s the next step for open source, but it will take committed UX people who are also politic enough to sell developers doing things in their free time to use some more of that time to do things right.

> UX people who are also politic enough to sell developers

This, 100%. UX doesn't respect development because devs tend not to care about UX. Development doesn't respect UX because UXers tend not to care about development.

IMHO, devs tend to assume everyone is a programmer. And many people are very much not.

Which is why even graphical OSS tends to look and work like... git.

"People working on open source are hobbyists doing it their free time" is such a tired idea.

Here is a thought: do you want committed UX people working on open source? PAY THEM!

If every developer set aside a budget of 5-10% they spend on proprietary services to contribute to the funding of open source projects, there would be enough to attract hordes of UX professionals.

It amazes me how much of a premium people for, e.g, Apple products yet can not plan to spare 5-10 bucks a month to support R&D of open source.

My first impression was that the software was from (as in, last updated) around 2008, possibly earlier. It has a very Windows XP era vibe.

Exactly. Not even 2008, maybe dotcom era.

Definitely. It even vaguely reminds me of some GUIs written on top of MSDOS, before Windows became popular.

There are plenty of great OSS that looks great but they are often backed or owned by a real company and not just a community project. Gitlab, Firefox, VLC, Blender, VScode or BBB, Jitsi Meet for videoconference...

Most of the projects you listed, aren't developed in the `Bazaar` environment. They have a complete team with managers, designers and developers working full time in cohesion. They are cathedrals, who open sourced the product.

I wonder if the disconnect is that the phrase "open source" refers to "source code," and UI designers who would otherwise feel able to contribute may think "I don't produce source code, I produce [whatever artifact of their process]; too bad the pull request workflow only collects source code and a readme."

If I'm correct to suspect that this train of thought might exist (and not only keeping UI designers away, but all sorts of related professions like product managers, marketing, etc.) then maybe the whole notion of "[product] is open source, contribute to the source code or issue queue" needs to be rebranded as "[product] is an open collective work, contribute in any possible way" with a collaborationware workflow that doesn't consider changing the source and filing issues (bugs, feature requests) to be the only first class citizens.

Many projects do have communities with robust organization of leadership, management, branding, etc. but with real or perceived barriers to entry that don't give the same sense of openness and "everyone can contribute to this well-oiled contribution intake machine" in non-code aspects akin to what developers enjoy.

My guess is that developers that want to do something start coding and hammer out any UI that barely works. On the other side UI designers that want to do something don't start coding because they usually can't code. Their free work doesn't make it into open source. Do they even do free work? No idea. Any UI designer here?

I was thinking the same thing, then I saw the next story on the home page:


I posted that because of a comment down-thread here:


That was the first thing I thought. UI is super important, and I hate when I see great projects suffer because they're.. well, ugly.

It's time to separate UI from logic (finally). Let the UI guys make UI projects that hook onto engines made by backend guys. Why one frontend? Let the community come up with a few and don't let a backend engineer and their practices and ideas anywhere close to a designer, the former will suffocate the latter with their total lack of vision and sensitivity.

I thought this comment was a bit overblown until I clicked the link. And then I audibly snorted at how bad the UI was.

You're not wrong, but feel free to scratch that itch, I'm sure they'd welcome a patch.

Companies spend a lot of money on tools like Zoom. If instead they donated a couple of man-days to projects like OpenMeetings or Jitsi, these tools would be in much better shape and we'd all have free conferencing software.

I wish I could! I'm not preaching anything here, my own personal projects look nothing better than this, as I'm a developer, not a designer.

And even if I was a UI/UX person, I think this is a deeper problem than a patch could solve.

Hello, do you know how or who should I approach in order to offer my studio's professional services (for free of course) for tackling this UI problem? I want to commit to this, but with some kind of planning, just blindly sending PR's seems like its not gonna be throwing hours go the void.

I think most companies, especially now, want a turn-key solution with support in case of an issue. The fact that Zoom, Teams, GoToMeeting, WebEx and Google Meet are closed sourced is a non issue for most organizations. They want something that works right now.

To be fair, zoom feels the same. Utterly incoherent and ugly UI without any thought for UX. But it gained a lot of traction. So maybe it's not that important.

Man, just what I popped in here to say too. Looks like something from the late 80s.

Here's the "open stack" I've been trying to use for communications, veering towards web standards and open source:

Video with lots of participants: https://jitsi.org/

Video with a few participants: https://whereby.com/

Internal chat with tech-savvy folks: https://element.io/

I still use Slack and Zoom pretty often. People already know, love, and have installed these tools. It adds significant friction to expect everyone to use the tools you want, especially if they don't share certain values around technology, or if they're slow to adapt to new user interfaces.

I wish for a videoconferencing tool that:

- Built on open standards and runs fine on browers

- Is licensed Apache 2.0, MIT, or 3-Clause BSD

- Has slick native apps across GNU/Linux, MacOS, and Windows

- "Host yourself" server that scales horizontally, allowing me to throw more servers at this

- Supports screen sharing, recording, and transcription or integration with a 3rd party service

- Has an open chat API that allows you to hook up custom bots during meetings (Zoom is lacking this feature, but it's very important to me)

- Has other APIs build into the core workflows of conferencing, not implemented as an afterthought

- Supports an operating mode up to 100 simultaneous connections of HD video and audio

I would pay $30/mo per "host seat" for a SaaS implementation of the above.

If you ever get the itch to run this on AWS cloud, just don't. I ran Jitsi ( the whole system) on AWS on-demand EC2 for my Kid's class to collaborate on their projects during Covid lockdown (in Toronto) and it burnt a hole in my wallet. Not prophbitively expensive but still. So now I advise them to use Google Hangouts or Zoom. I often wonder how much Zoom and its competitors pay for bandwidth.

Very little, because AWS and GCP bandwidth costs are marked up by over 1000%.

Cloud services are sold the way drugs are.

The first hit is free. But after a tiny bit of, uh, scaling you're going to be ripping copper out of abandoned houses to make ends meet.

Do you happen to have the bill/invoice still? I'd love to see some real numbers, and try a bit of back-of-napkin comparison with digital ocean, scaleway, hetzner cloud - and in particular hetzner dedicated. The latter does cost a bit if you need 10gps uplink - but otherwise you could go far with a "second hand" auctioned server - free/included bandwidth (1gbps) and no setup fee. I suppose for the US market one might want to look at ovh as well.

Some competitors like Cisco opt to deploy their own AS (Webex is AS13445) optimized towards eyeball networks because capacity and latency to Google and Amazon can be tricky with some incumbents. So they generally have good control over their cost this way.

Yes, it's much more affordable to use a host like linode which can provide more reasonable rates.

So, a souped-up Matrix Server with Jitsi integration and a bunch of other plugins?

I'm not ready to offer that to you, but it's definitely on my roadmap for https://communick.com next year.

The thing that I'd suggest though: instead of coming with a laundry list of things that you'd like to see in a finished product, consider funding the development of projects that provide the pieces?

One of the pain points of Jitsi to me is the client-side muxing of media streams causing load shifted to laptops and phones, so not sure if Jitsi would work with this.

Does your service allow exporting data?

Yes, if you count that the services I am using (Mastodon, Matrix) provide methods to export the data directly from their clients.

If you want to get the data from your account (payment history, services you used, people you invited, etc) you can get that only via the API or semi-automatically if you request your data and I run my "export user data" back-office command.

Well, the thing is that you won't find a standalone product that does all this, because it's already difficult enough to get right some of those requirements on their own. These are just different verticals, so what you need is somebody who decides to integrate them into a cohesive final product. For that, the integrator will need to base off intermediate implementations of each vertical (or have huge resources to reinvent the respective wheels from scratch...)

Like for example OpenVidu [0] offers a platform over which standards-based video-conference products can be written. It takes care of WebRTC stuff, STUN/TURN/ICE shenanigans, user permissions, recordings, etc. so you can focus on e.g. building native apps with your desired chat solution. And even then, it in turn delegates the low-level WebRTC media transmission to Kurento, of which (disclaimer) I'm the current developer and maintainer.

[0]: https://openvidu.io/

We don't check all of your boxes right now, but we've been working on an API + app store for video chat apps. https://align.link/

Https://etherpad.org for real time Collabo doc editing.

Oh man. I want to like Apache products, or maybe “projects” is more accurate. It’s really quite the dumping ground of random things. I’ve tried so many of them, and it feels like it’s mostly a random professor implements something to justify his of her position at a university, gets it approved for Apache to get more prestige, has students add random bits every year. It’s just all so uncohesive within itself, or as a whole.

Like, you might not like Microsoft Office, or the Mac suite. But at least you don’t end up with Microsoft Word, Mac Numbers, Gmail, Office 365 notes, and pretend that everything is one office suite.

Apache really needs to define and enforce some unifying standards.

Or we need something un-Apache that can do this for open projects.

The ASF board's job isn't to enforce "standards." It's intentionally an open community-driven group, which means there's going to be a wide range of projects.

See my response to yc-kraln:


Software goes to the Apache Foundation to die. Biggest proof is Openoffice.

I only use Open Office. It suits all my needs

You should try LibreOffice

I'm genuinely curious, is there any organization that actually uses this or would? Not experimentally, but as a rational cost/benefit choice?

I wholeheartedly applaud their motivation in building this... but these are mission-critical tools for businesses and organizations. And this product is competing with Google, Microsoft, Zoom, etc. who have literally thousands of developers working on these things.

And it's not like Google/Microsoft charge exorbitant amounts for their products, and they even have free tiers for things like education, nonprofits, and consumer use.

So I love the hacker spirit in this... but at the same time feel like I have to realistically question what it's leading to?

Your argument sounds like many I heard about Linux in its early days.

If enough hobbyists, hackers, and businesses see an interest in owning and controlling their video conferencing platform then it doesn’t matter how many people Zoom employs.

There’s no way to know what this leads to. There is a good chance your concern will be realized and this will go the way of many Apache projects...

The difference, though, is that using Linux or even LibreOffice is or can be an individual decision, so it's much easier to casually and gradually adopt.

Collaboration software, however, is necessarily an organizational decision.

(And hobbyists and hackers generally get by with just message boards, wikis, etc... so it's really only about businesses.)

What is it about open source that it can't attract UI/UX designers to try and contribute? Are most open source projects just unwelcoming to that kind of help? Missing tools/platforms for it, or something else?

A lot of times, like in this case, I wouldn't even consider the product because of its bad UI/UX, even if the underlying technical implementation might be slightly better than the closed source alternative.

My longstanding explanation for this has been as follows:

* Improvements to open-source projects come primarily from developers scratching a personal itch.

* User interfaces are first and foremost a way for the application to communicate to the user what is possible and how to achieve it.

* If there's a problem with a user interface, it therefore most adversely impacts a user who does not yet know what is possible or how to achieve it.

* To fix a problem with the user interface, you must learn enough about the application such that you now know what is possible and how to achieve it. Hence the problem no longer affects you as much and is no longer a personal itch. So the problem doesn't get fixed.

I agree with the above, and also would add the following:

* There is usually no clear way for a UX designer to contribute. Note with this example, under 'Contributing - Tasks I could work on' it doesn't mention UX, and the only way to become a committer is to "show us some of your patches, or solve some issues" - none of which involve UX.

* There is a slight obsession in the open source community to use only using open source tools, while the majority of modern UX practice is developed on proprietary tools (e.g. Figma).

* Design by committee is the most frustrating and slow process, and great UX design comes from strong decisions by great designers rather than community votes.

* There is an underlying assumption that if you contribute UX designs and put them in the Wiki they will be ignored, so there is no point. It's not the same as code where there is a one step process (i.e. commit), the whole team needs to embrace the UX and then work to commit it to code.

> * There is usually no clear way for a UX designer to contribute. Note with this example, under 'Contributing - Tasks I could work on' it doesn't mention UX, and the only way to become a committer is to "show us some of your patches, or solve some issues" - none of which involve UX.

This affects not only UX. I'm sure I'm not the only one who has spare infrastructure and ops skills that I'd love to contribute to open-source projects - hosting CI/CD, repo mirrors, staging environment, website, chat server, SMTP gateway, for example. It'd be nice to play a small part in decentralization, for one thing.

I'm sure I'm far from the only one. I'm also sure there are open source projects who would benefit from it.

There's no process for us to match and it seems just culturally abnormal. I'd love to hear ideas.

> slight obsession in the open source community to use only using open source tools

While true in some aspects, it's not true in others. Most of todays "modern" open source ecosystem live within GitHub which is not open source, using services for development and infrastructure that is also not open source. While many developers local tools tend to be open source, the rest of the infrastructure we use tend to not be open source. Even many of the biggest package registries for open source are not open source themselves.

I'm not saying 100% of the open source community leverages these services, but a lot sure do.

I agree with your top most point the most though, there is no clear path for designers to actually contribute. And if there is, it's a pipeline of "come up with requires -> design -> code", whereas contributors are not as excited about the last point if someone else did the steps before. Hence we see more code contributions than design ones.

> While true in some aspects, it's not true in others.

Open standards might have been a better term. The example in this project would be the use of "Pencil Project" for UX design rather than Figma / Sketch / Adobe XD (which to some extent may be for licencing and cost reasons too).

Funny enough, Pencil Project in itself is a testament to how badly open source software needs better/more designers who know good UX/UI. Try putting a modern designers coming from Figma/Sketch in front of Pencil Project and watch them puke colorless rainbows while trying to figure out how to do the most basic of operations.

Figma, because of the cost (or lack off) and availability, seems to be the only tool realistically available for doing open source design today. Unfortunately neither the format nor the editor is open source itself, but sometimes the means justify the end I guess.

Figma is able to import and export svg files pretty well (for my purposes) - I wonder if that's sufficient for a good number of workflows/projects?

I doubt the click-through presentation stuff can be exported in any way, but basic design work could be persisted and collaborated on by multiple people with different tools if that approach was used.

Yeah, SVG import/export for smaller elements works fine but once you get into larger files, design systems or designing entire applications in Figma, import/export of SVGs becomes untenable. Otherwise you just have the .fig file format, which is also proprietary as well.

Currently for my open source project, we all just work directly in Figma then export the design to a website via the tool we're building. Works fine for now, but not doing anything too complex. Project is https://github.com/instantwebsite in case you're curious.

I like this list :)

I'd add to it that developers are the ones birthing these projects, and they (or we, I should say) don't like to be bottle necked by UX.

Thank you, and I agree with your point.

My comment is intended more as a step-by-step argument rather than a list.

On design forums I've often seen people using their spare time to create an alternative design for various services / programs. They often look very sleek, and people will comment "wow, they should make it like this" or "I would use program X if it looked like this". The problem is that these mockups are often useless. They are just drive-by. No substance, no thought of a user-journey or how to accomplish tasks. Mostly all functionality has been hidden and some pretty colors added. (And these mockups never reach the projects anyway, just shared with other designers)

Whats needed is first and foremost UX people, not graphic designers drawing a pretty UI. That is the final touch. But making good UX is hard, and need a good understanding about how the software is used, and what's technically feasible. All this takes much involvement and speaking to multiple people and back-and-forths over time.

My day-to-day involves a UX person discussing a feature with me, and us arriving at some rough sketches for how it should be. I will often start implement, and find an edge-case not considered or something, which will trigger a new discussion. My point is that UX isn't something someone can do in a vacuum on their own, or as a complete rewamp. It needs to be continuous in the process for every user-facing feature, and thus involve everyone.

Attracting UX people to that kind of long commitment is the hard part. While for a developer I often feel it's them just making a feature to scratch their own itch, with no consideration for the whole.

My guess is always that if a designer comes along and suggests a new interface or creates design components that can be used that maybe need some engineering resources the priority will always be on "let's make it work first and support all these edge cases we programmers like to think about".

With most projects already stretched pretty thinly on engineering resources that's the natural outcome even if it would be better to have less features, but easier to use for a beginner or regular person before building out the whole thing.

>What is it about open source that it can't attract UI/UX designers to try and contribute?

How would UI/UX contribute? Would you want them to do a pull request with wireframe mockups?

To whomever downvoted this: I'd assume that you misunderstood this comment. How I understood this comment is that there's no easy or defined way to contribute UI/UX improvements. For code improvements it's pretty clear, but the whole issue/PR workflow can't be applied 1:1 to the UI/UX process works from what I've seen. So I'd definitely agree with that sentiment.

An additional challenge is that, if I get a PR of which I don't like the specific way it's been done, I can patch it up myself. And if it's a feature I don't want added at all, I can already turn it down at the proposal stage, before any code is written.

With UX, however, the contribution itself isn't the proof that the contributor actually knows what they're doing. I've been excited about getting a UX contributor in the past, but then with all due respect what they turned up with was even worse than what I could've done - and this was not just a matter of taste and expertise. But it's rough to turn it down after the work's been done.

> But it's rough to turn it down after the work's been done.

If the work suddenly turned up with zero iterations and input, this is UX work being done wrongly.

Sure, but just delivering the first iteration is already a significant step up from just reporting an issue describing your proposed approach, which is how it would work for writing software.

Actually I'm a UX Designer and tried to contribute to open source projects, but it seems that it's always about graphic degin. Anyway, I'd be glad to contribute to some projects that need UX, if you know some, let me know!

Hi, KDE is interested in more UX designers: https://community.kde.org/Get_Involved/design

Thank you for sharing, I'll get in touch!

The GNOME community has some UX design folks, it would be a good idea to get involved there. Probably KDE would appreciate design folks too.

See also the open source design site, some of the jobs there are even paid:


Thank you for sharing, I will take a look!

I split my time between front end development and UI/UX design. I believe this is because achieving a good UI/UX requires a holistic knowledge of the entire software suite, and detailed information about who is using the product and for what. This kind of thing takes a ton of research, and it's the kind of thing that only a BDFL working side-by-side with a talented UI/UX designer can achieve. Basically, it takes a small group of people with a vision, who know the product and the user very well, and can afford to spend dozens or hundreds of hours on it. This is not something that most open source projects have, unfortunately.

I think the contact info in your profile may be out of date?

I can think of a couple of issues that may add some friction:

- Adding good UX to an existing project is a huge undertaking. To do a good job you probably want to touch just about every piece of the UI. This can be a hard sell as a new project member.

- Many designers don't have the skills to implement their design. This means that the best they can do is basically propose that other contributors do a lot of work. It is a lot easier to just merge a PR that works then implement a design.

- The maintainers of projects are probably more familiar with accepting code patches. They know how to evaluate code but don't have a strong ability to review UX proposals.

I have a bunch of small tools that I maintain and that occasionally get code contributions. But I know that they have terrible UX. I would be thrilled to get some support in that area, however if someone without frontend experience just proposed the end result. I don't know if I would have enough motivation to implement it myself. Of course I suspect that a skilled UX Designer with frontend development experience would be a very welcome contributor to many projects.

The screenshot of the documentation looks nice

> What is it about open source that it can't attract UI/UX designers to try and contribute?

Well, presumably they'd want to be paid.

I don't think that's the full reason, there's a lot of designers on Twitter / Dribble / Producthunt that build side projects or share free resources just like programmers.

There are some paid open source design jobs here (amongst unpaid ones):


Having used both Zoom and Teams, I’m actually impressed at the feature set and granularity of control. Ok sure the UI isn’t great but come on it’s free.

Genuinely surprised there's so much focus on UI/UX here. Of course, it's FOSS, I always thought it went without saying it doesn't look as good, but indeed, this looks pretty robust for what it is.

My #1 priority for WebRTC is, someone needs to build some APIs.

We should be able to bring whatever client we want. That each of these different solutions is totalizing, that everyone has to use the same site, the same client, to talk together, is most unfortunate.

With better protocols, I could use a client that works for me, you could use a client that works for you. As the stack expands this gets problematic- white boards, messaging, document editing- these are additional concerns, & are good to have, part of the package, but I'd like to see video chat made interoperable as a starting place.

Unfortunately, clients and features are still rapidly evolving and there's absolutely zero consensus on how to standardize any of it.

P2P vs centralized server? Different encryption models? Different algorithms for who is the active speaker? For how many and which audio channels get mixed and when? What about features like muting someone else or if there's a host or multiple hosts?

All that's just basics before we get into even the simplest extra but still required features like raising your hand, chat, file transfer in a chat, and so on.

As someone who's worked in the space before, there's no obvious or non-controversial way to do any of these. The "common sense" implementation that works in a business meeting case is often the exact opposite of what you'd want in a remote learning classroom, both of which are totally different from a government meeting.

And then at a practical level, differing clients would lead to madness as well. Imagine a training session where the host asks participants to click the "raise hand" button on their clients when they have a question... but half the clients don't implement one, and the other 5 clients have it in different places in their interface and everyone's confused. No thanks. :)

The MVP seems extremely simple to me. Because WebRTC more or less "just works", if it has a list of peers! It's a miraculous age. Sure, it's a limited set of "just works", it doesn't scale to 50 users, but there are demos that use less than a dozen lines of code to let the user manually enter IP addresses & start video chatting with a couple friends, in a nearly universal manner.

To me, it feels like there's only one thing missing, & it's pretty basic. There's dozens of different choices for signalling servers, to help figure out who to peer with in webrtc. But they are all single-origin centric. All that's really needed to begin to allow cross-service video conferencing is a signalling service that can collaborate across domains. Some protocol to let the two signalling services exchange peers with each other.

> and there's absolutely zero consensus on how to standardize any of it.

The ecosystem feels beholden to a very vendor-centric project-centric perspective. I don't think most folk who deal with webrtc have much interest in trying to work together, to try to standardize. Which is really sad, because I think forming some good core basis to begin to work together from would help us all move much faster.

> All that's just basics before we get into even the simplest extra but still required features like raising your hand, chat, file transfer in a chat, and so on.

Yet another reason why I am 98% convinced that xmpp is actually what we need to do all our signalling atop. MUJI was ok[1]. We need to rebase it from the crufty/bad MUC/Multi-User-Chat system to work atop the newer[2] MIX/Mediated Information eXchange system. Either one will "solve" almost all these federated peering questions, easy. Then we can go about figuring out how relays &c work in this world.

And with that basis, 80% of these other concerns would be weekend projects to write specs from. Raising hands? Done. Chat? Already have that. File transfer? Well specified.

You're right that there are a lot of questions, problems, issues. But mainly I think it's the lack of will to tackle this problem in a cross-domain manner that's holding things back, and that is keeping us kind of tied into this cruddy local maxima, a bunch of competing products, versus a more dynamic interesting & useful & evolving space. I see plenty of people hemming & hawing & complaining about XMPP clients having different feature sets, but in practice, things work extremely well. Detecting & notifying when someone's client isn't capable is usually handled very gracefully & clearly. The Fear Uncertainty & Doubt, it feels to me, often is unwarranted; for the most part it turns out highly extensible systems work quite well & robustly & the occasional mismatches can be dealt with in a quick manner, & hopefully, over time, more consensus emerges & good features roll out. For ex, OMEMO encryption once was rare in XMPP, now it's expected.

I don't know how to sum this all up. Because I recognize what you are saying, and there are bedevilling complexities in all of this. But it also feels imminently close, doable, especially if we rely on the really good tech we already have (XMPP, &c), which seems like it should suffer many of these same problems, but which, it turns out, works pretty great. I don't see the barriers to the better world as technical. I see us as spending a lot of time building independently, & coming up with excuses for why we are not building together. And I think few folks working with WebRTC prioritize interoperation at all, which is a huge root cause of the slowness of the universe.

[1] https://xmpp.org/extensions/xep-0272.html

[2] https://xmpp.org/extensions/xep-0369.html#concepts-muc-compa...

We've been working on something to help out with this: https://align.link/

It looks terrible and lacks any sort of decent UI/UX, and this will kill adoption.

Of course, it's funny to see this on the same day as https://opensourcedesign.net/ reaches the front of hacker news. Maybe they should get together.

I posted that because of a comment down-thread here:


This trend of Apache projects suddenly landing on earth with a massive feature set and ecosystem is quite puzzling. Isn’t the foundation supposed to accept and fund _already successful_ or relevant projects instead of pumping out their own, as if they were a tech company?

I'm not quite sure what you're trying to say. OpenMeetings has been around for more than ten years. The feature set and ecosystem didn't appear out of thin air.

What makes you think that the ASF is supposed to only support "already succesful|relevant" projects? The ASF doesn't "support" projects. A project either is or isn't an ASF project (though it might be incubating or retired). They have over 300 projects. Some of which are very successful or relevant, some of which are less so. But it's always up to the ASF to decide which projects to keep going.

Wow, the UI looks absolutely horrible, and the text on the product page is filled with typos (Openmeetings vs OpenMeetings) and grammatical mistakes. This makes me want to avoid all Apache projects from here on out.

They need a UX/UI person, badly. They should also just call it "OpenMeetings", and ditch the Apache moniker on their products. Normal people don't know who or what Apache is. They don't care. At best, it'll confuse them. At worst it'll make them afraid to install it. Just market "OpenMeetings", but for goodness sake, pretty it up first.

Why does it feel like the Apache project has become a dumping ground for unwanted (and partially unmaintained) garbage?

Apart from a few projects (Apache httpd, Hadoop, OpenOffice) it looks like a dumping ground for open source projects which have lost their original way or otherwise would not be a good idea to use for any modern project, many of which are writen in Java

Disclaimer: Apache member and former board member here.

A couple of points:

The goal of the Apache Software Foundation is to provide a proven, reliable governance model to open source projects which choose to join. Governance models aren't (generally) exciting, but they're really important for _mature_ projects that grow beyond the original developer or team. The ASF provides things like:

- A contribution model that allows for clarity around copyright ownership

- A nonprofit that makes it easy for individuals and companies to interface with

- Clear rules around project ownership and decision making that are oriented for _community_ ownership as opposed to ownership/sponsorship by a specific company or individual.

That last point is what particularly distinguishes the ASF from organizations like the Linux Foundation which is more suitable for direct corporate involvement.

As a truly community driven organization, the ASF doesn't have an agenda or policy to pick and choose which projects join. We don't go hunting for popular projects, we don't have a portfolio we need to fill out. Any community of developers is invited to join as long as they agree with our principles. So that means we get everything from an open source project being "donated" out of some company to a scrappy group of developers trying to grow their project.

As for Java, that's a historical point in that many critical open source Java projects in the early 2000's found their home in Apache. And while the ASF tends to have projects that fit the "internet middleware" shape, we have communities that range from desktop software to core libraries in diverse range of languages.

> Apart from a few projects (Apache httpd, Hadoop, OpenOffice)

You must have missed that OpenOffice belongs to the dumping ground part of projects, not on the successful side. It's not well-maintained, most contribution went to LibreOffice for the last 10 years. (Although after 10 years of success, also LibreOffice might be facing hard times https://lwn.net/Articles/833233/ )

I'm happy to see that they've added WebRTC support. No more flash!

Arggg! Don't use carousel!

so.. like bigbluebutton?

I’m amazed at the high quality of the interface—this is clearly going to crush Zoom. If I were the CEO I’d step down immediately and I wouldn’t show my face for the rest of my life.

The ironic thing is zoom is such a terrible interface. Sure the calling part is really straight forward, but all the other features are all over the place and completely unintuitive, for some things you use the chat, for other the participant list, for others there is an option hidden somewhere else. IMO got big because of marketing largely, otherwise I can't explain it.

Zoom got big because the average Karen could get into a meeting quickly, without cognitive overload, and with good performance even with modest hardware and connection.

2020 is not the year of the power user. It’s the year of new users. A ton of people used meeting software for their first time in their life this year.

"could get into a meeting quickly, without cognitive overload"

If that were truly the biggest driver, then jitsi would be the clear winner by a very long stretch. Send the user a link, they click, they're in the meeting. Even as a supposed "power" user I found my first experiences with Zoom to be frustration filled and far from intuitive.

Jisti is a great product. But of course, Zoom's early momentum (and having > zero ads) was undoubtedly a factor.

I use jitsi in production, but I actually did not realize at the beginning of this year that their hosted version was intended to be anything more than a demo. Their .org page (earlier in the year), linked their GitHub and highlighted the project as a self-hosted tool. They have since updated the page to be written for a general audience.

Here, you dropped this: /s

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact