Apache OpenMeetings – Video chat, messaging, white board, doc editing and more
openmeetings.apache.org
openmeetings.apache.org
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.
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.
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.
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.
And even if I was a UI/UX person, I think this is a deeper problem than a patch could solve.
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.
Blindside's commercial element is to to consult on educational deployment of the software (which is its intended use).
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.
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
When I click 'start', I'm taken to https://demo2.bigbluebutton.org/html5client/join?sessionToke... which is a 404 Not Found page from nginx.
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.
It’s a uni so they probably adopted the throw-ideas-at-the-wall-until-it-sticks approach
I also agree that Java attracts a certain kind of developer.
> 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.
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.
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.
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?
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.
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.
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/
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.
See my response to yc-kraln:
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?
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...
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.)
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.
Well, presumably they'd want to be paid.
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.
How would UI/UX contribute? Would you want them to do a pull request with wireframe mockups?
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.
If the work suddenly turned up with zero iterations and input, this is UX work being done wrongly.
* 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'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.
My comment is intended more as a step-by-step argument rather than a list.
* 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.
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.
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).
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.
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.
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.
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.
See also the open source design site, some of the jobs there are even paid:
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.
- 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.
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.
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. :)
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...
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.
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.
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
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.
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/ )
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.
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.
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.