Find It makes it easier for a small team in government to make sure that there are resources available for a variety of residents' needs.

We can look at the recent popularity of some widely used platforms like Zoom and ask ourselves some questions as to why we still use them when we know a lot of terrible things about them. Agaric prefers to use a free/libre video chat software called BigBlueButton for many reasons, the first one being the licensing, but there are many reasons.
Zoom has had some major technology failures, which the corporation is not liable to disclose. At one point, a vulnerability was discovered in the desktop Zoom client for MacOS that allowed hackers to start your webcam remotely and launch you into a meeting without your permission. The company posted a note saying that they fixed the issue. Unfortunately, the Zoom source code is proprietary and we are not even allowed to look at it. There is no way for the community to see how the code works or to verify that the fix was comprehensive.
The Zoom Corporation stated early on that the software was encrypted end-to-end (E2EE) from your device to the recipient's device. This was untrue at the time, but the company states that it has been corrected for users on their client app. While it is no longer true that E2EE is unsupported, it does require that you use the proprietary Zoom client for E2EE to work. Without E2EE, any data that is retrieved on its way from your computer to a server can be accessed! The only real security is knowing the operators of your server. This is why Agaric uses trusted sources like MayFirst.org for most of our projects and we have a relationship with our BigBlueButton host. The Intercept also revealed that Zoom users that dial in on their phone are NOT encrypted at all
BigBlueButton does not have a client app and works in your browser, so there is no E2EE. The idea for E2EE is that with it, you "do not have to trust the server operator and you can rely on E2EE" because the model implies that every client has keys that are protecting the transferred data. However: you MUST still use a proprietary client in order to get the benefits of E2EE support, so once again you MUST trust Zoom as you have no permission to examine the app to determine that the keys are not being shared with Zoom.
Of course there is always the fact that hackers work day and night to corrupt E2EE and a Corporation is not obligated to tell you the customer every time there has been a security breach, and this information is usually buried in the terms of service they post - sometimes with a note saying the terms are subject to change and updates. A Corporation is not obligated to tell you, the customer when there has been a security breach" unless any personal information is exposed. There are now mandatory timely disclosure requirements for all states: https://www.ncsl.org/research/telecommunications-and-information-technology/security-breach-notification-laws.aspx ...Can Zoom really be trusted? As with some laws, the fine that is applied is low and affordable and subject to the interpretation of the courts and the status of knowledge your lawyer is privvy to - meaning most Corporations normally have a battery of lawyers to interpret the law and drag the case out until you are... broke.
In the case of BigBlueButton encryption, E2EE would only make sense if there are separate clients using an API to connect to the BBB server so a user does not have to trust the BBB server operator. If the user trusts the server operator, then there would be no need for E2EE." Lesson learned: It is always best practice to know and trust your server hosts as they are the ones that have the keys to your kingdom.
Some technology analysts consider Zoom software to be malware. Within companies that use Zoom, employers are even able to monitor whether or not you are focusing on the computer screen during meetings which seems excessively intrusive. Speaking of intrusive, the Zoom Corporation also shares your data with FaceBook, even if you do not have a FB account - that could be a whole blog in itself, but just being aware of some of the vulnerabilities is a good thing to pass on. Some of the bad stuff remains even if you uninstall the Zoom app from your device! Even though a class action suit was filed over privacy issues, the company stock still continued to rise.
Those are many reasons why we do not support Zoom. But there are also many reasons why we prefer BBB over Zoom. Besides, BBB has many great features that Zoom lacks:
1. Easily see who is speaking when their name appears above the presentation.
2. Chat messages will remain if you lose your connection or reload and rejoin the room.
3. Video is HD quality and you can easily focus on a persons webcam image.
4. Collaborative document writing on a shared Etherpad.
5. Easily share the presenter/admin role with others in the room.
6. Write closed captions in many languages, as well as change the language of the interface.
7. An interactive whiteboard for collaborative art with friends!

One huge advantage of free software, like BBB, is that you can usually find their issue queue where you can engage with the actual developers to report bugs and request feature enhancements. Here is a link to the BigBlueButton issue queue.
So, why do people keep using a platform like Zoom, even though there are many features in BigBlueButton that are much better?
There is very little publicity for free software and not many know it exists and that there are alternative solutions. You can find some great suggestions of software and switch to it by using this site called switching.software. The marketing budget for Zoom is large and leads you to believe it has everything you will need. Sadly their budget grows larger everyday with the money people pay for subscriptions to the platform. As a result, many people go with it as it is already used by their friends and colleagues, even though there are reports of irresponsible behavior by the Zoom Corporation. This is why the New York school system does not use Zoom and many organizations are following suit. The company gives people a false sense of security as it is widely used and very popular.
Of course, there are reasons to avoid other proprietary chat platforms too...
Agaric offers BigBlueButton for events and meetings. Check out our fun BBB website at CommunityBridge and test drive the video chat yourself!
If this discussion interests you, please share your thoughts with us in the comments.
Looking to learn more about problems with Zoom? There are a lot of articles about Zoom scandals.
Looking to learn more about protecting your privacy online? These links have some helpful information and videos for tech-savvy people and organic folks alike!
2021 could be the year we all begin to STOP supporting the Corporations that oppress us.
Special thanks to Keegan Rankin for edits!
Ayudamos a las organizaciones a cumplir sus objetivos y fortalecer el movimiento de software libre al proporcionar consultoría en estrategia de tecnología en línea, al crear y personalizar software de alta calidad, capacitar a personas y hablar en eventos.

Utilizamos los principios de justicia de diseño para ayudar a que su presencia en línea alcance sus objetivos y tenga un impacto en el mundo real.

Construimos con un software probado que le da poder y control sobre su sitio web y presencia en línea.
Usamos y contribuimos con el software libre siempre que sea posible, Creative Commons licencia nuestra documentación y trabajamos bajo un modelo de organización abierta.

Asesoramos y enseñamos, aprovechando su experiencia actual.
Obtenga más información sobre las oportunidades para recibir capacitación de Agaric.

Compartimos nuestros conocimientos y promovemos el software libre hablando en eventos.
Los temas incluyen:
Reserve con nosotros para un próximo evento.
Originally published on the Nonprofit Technology Network's Connect Blog.

Most of us don’t look at our site analytics. At least, not often enough. We know we should, but life gets in the way. How do we make it easier for nonprofits to truly take a “data-driven” approach to their work?
I’ve found success with putting the analytics where people will see them. One of those places is the website itself.
There’s no shortage of data to review. So, it’s important to move beyond vanity metrics and get to the heart of why we do what we do. This means turning to the goals and key performance indicators you have for your website (or defining them for the first time!).
For my work at Agaric, those goals are:
1. Secure well-matched projects by communicating the value we provide to potential clients.
Key performance indicator: feedback on design and content from target audiences.
2. Diversify and expand free software communities by sharing relevant knowledge.
Key performance indicator: pageviews of blog posts.
Each goal should be accompanied by at least one key performance indicator. This is data that tells you how successful you are being at reaching your goal.
In our case, our first goal of feedback is best measured qualitatively by asking our current clients— and those who we like working with—what they think of the website. We conduct interviews to gather that feedback. For our second goal, we can get a good picture of content relevance by pageviews, a valuable data point to share with the team.
A different site might try to increase one-time donations, in which case seeing the number of donations made during a campaign would be helpful. Another group might focus on building a regular readership, therefore email list sign ups are the best indicator of success. Whatever it is, make sure you can link the analytics you are tracking back to a goal you have for your site. There’s no point in measuring something you won’t take action on.
After identifying your key performance indicators, decide who on your team should review that data.
For our six-person worker-owned cooperative, that answer was easy – all of us. We all blog and we all have a vested interest in helping our free software communities thrive. We want to know which posts are resonating the most.
After knowing your target audience, find out where they spend their time. In our case, it’s the website’s back-end content overview page. Our website admins go here to pull up a page we want to update and to see what posts are still in draft mode. So, we added a column for pageviews and made that column sortable.
This content overview page was customized to include each post's total pageview count.
For the independent news site Portside, the same was true. In addition to showing pageviews on their content overview page, they also include them directly on each post (visible only to content editors).
Showing the pageview count on the page itself makes it clear to content editors how popular it is.
For the online educator portal Teachers with Guts, the organization wanted to track several data points on their members’ use of the platform. So, they have a report page built into the site showing information such as the number of downloads made, comments left, and pages bookmarked.
Teachers With Guts began tracking user engagement to inform how they manage their online portal.
Other opportunities to share analytics include weekly email reports, a user dashboard upon logging in, or via mobile texting or apps. Don’t be shy about asking your team where they would most likely notice the data you’re sharing with them.
By showing key data in high traffic areas, you foster an informed team. From there you can have the conversations you want and need. We now know which posts are getting the most reach and are evaluating why that is. As a result, our best practices have evolved to make our writing more relevant with readers.
This month, the National Institute for Children's Health Quality is celebrating Agaric's support in making the most of the digital health revolution, part of their 20th anniversary campaign.
It got us thinking about how long we've been working in the space. Indeed, Agaric is proud to have been helping medical and scientific communities almost from our founding.
In 2008, we started building biomedical web communities enriched by semantic data. Working with researchers Sudeshna Das of Harvard University and Tim Clark of Massachusetts General Hospital, both affiliated with Harvard's Initiative in Innovative Computing, we were the primary software developers for the Scientific Collaboration Framework, a reusable platform for advanced, structured, online collaboration in biomedical research that leveraged reference ontologies for the biomedical domain. Making use of academic groups actively publishing controlled vocabularies and making data available in the Resource Description Framework (RDF) language, we built on work done by Stéphane Corlosquet, a lead developer in adding RDF to the Drupal content management system, to build the Science Collaboration Framework. SCF supported structured ‘Web 2.0’ style community discourse amongst researchers when that was a new thing, and made heterogeneous data resources available to the collaborating scientist, and captured the semantics of the relationship among the resources giving structure to the discourse around the resources.
Read more about it in Building biomedical web communities using a semantically aware content management system in Briefings in Bioinformatics from Oxford Academic.
Agaric led the work of building the website for an online community of Parkinson's disease researchers and research investors, on the Science Collaboration Framework, for the Michael J. Fox Foundation for Parkinson's Research.
In 2012, we worked with Partners In Health to create a site for people on the front lines of combatting tuberculosis to share and discuss approaches.
In 2015, we began contributing to the Platform for Collaborative and Experimental Ethnography. PECE is "a Free and Open Source (Drupal-based) digital platform that supports multi-sited, cross-scale ethnographic and historical research. PECE is built as a Drupal distribution to be improved and extended like any other Drupal project." We primarily worked on the integration of PECE's bibliography capabilities with Zotero's online collaborative bibliography services.
Also in 2015, we took on the exciting work of rebuilding the Collaboratory—a platform designed specifically to help improvement teams collaborate, innovate, and make change—for the National Institute for Children's Health Quality. We're proud to be NICHQ's 2020 partners in making the most of the digital health revolution.
All in all, we're impressed by our twelve years of building sites for the scientific and medical communities, and looking forward to helping shape a healthy future.
Wow, that was fun. The very first event for the Boston/Cambridge Worker Ownership Meetup group on October 10th, 2014, was a great success. We met at The Industry Lab, Agaric's new co-working headquarters and event location. We had a great discussion that was led by our friend Gonzalo Chomon of EvoVelo, a cooperative located in Spain.
Gonzalo Chomon shared a wealth of knowledge about the inner workings of cooperatives that engaged everyone from the start. About a dozen attendees talked about the different ways cooperative companies are structured, laws governing different types of companies in Spain and the US and about the different internal processes used to add or remove members from the group.
Attendees were very engaged in the discussion from the start. One member asked about the company structure, how does it work, are there contracts, bylaws? A cooperative company can be structured in any way the partners agree upon. Usually the company is formed as an LLC between the partners with equal shares, but that is not an absolute. An organization the size of Mondragon has an entirely different structure, it is a federation of cooperatives.
The pizza from The Just Crust rocked and was totally consumed by the end of the evening. Many thanks, to our friend Kay Van Valkenburg who brought some lush fruits and scrumptious chocolate chip and dark chocolate dipped cookies—oooooh. Thanks to everyone that came to the first Boston/Cambridge Worker Ownership Meetup at the Industry Lab in Cambridge, despite the brilliant New England weather.
We have already planned our next meetup for November 17th at the Industry Lab.
We will talk with Carolyn Edsell-Vetter, from A Yard & A Half Landscaping Cooperative, based right in Waltham, MA, about transitioning to a coop from another ownership/governance structure. Meet some local people that are currently working in successful worker cooperatives in any industry, doing what they love to do. Let's discuss how they started and how they continue to thrive in this economy. What are the benefits and what are the hurdles to overcome when forming a cooperative relationship with your partners?
Join us! Visit the Boston/Cambridge Worker Ownership Meetup, we have started to list some great coop resources and links, and if you are in the Boston area, let us know.
Sign up if you want to know when Mauricio and Agaric give a migration training:
We can modify any of the above courses to best suit your needs! We are also capable of teaching about many other aspects of Drupal. Look here to get a better idea of our teaching experience and expertise and how we can craft custom trainings for you and your team.
Clients and colleagues know Agaric developers for taking on the hard tasks when we collaborate on larger teams. We combine this expertise with the desire to raise people up. From our first projects fifteen years ago, our goal has been to make our clients need us as little as possible, to put as much power as possible in our client's hands. That is why we started using content management systems in the first place, and it is a tradition we uphold through developing with free/libre open source software, through writing documentation and blog posts, and above all through providing trainings.
Agaric is active in the Drupal community at-large and has presented at various Drupal Camps. We have also taken initiative in organizing Global Training Days in Nicaragua since 2013.
People contributing modules or themes for listing on Drupal.org receive a welcome, or lack thereof, that would have driven away many of us now active in the community. With hundreds of requests moldering awaiting review, the project application process continues to be a community crisis, and it has been acknowledged as such for five years. We are casting aside the literal future of Drupal, with a likely disproportionate impact on disadvantaged contributors. Any separate process for new contributors will inherently be unequal, and will tend toward awful. Let's jump in to mitigate the damage being done and finally get a new system in place— we're closer than ever.
After a couple frustrated module makers asked me to give their projects full status, I went over to the project application review queue out of the sense that it isn't fair to everyone else to save only the two who reach out. Of course, I should have been in there all along: there were project applications which had been vetted by other volunteers and marked Reviewed & Tested by the Community four months ago. One person who contacted me was unhappy their project had passed all the hurdles and was then left lying untouched for a mere two weeks. Of course, they had started the application process nine months ago.

The door through which community members can make their first contribution of a module or theme remains locked, and not enough people have the key (nor is it clear how to get that key to more people).
Keep in mind this is only projects that have actually been reviewed. In nearly every case the person applying has fixed the issues noted and now the project has been considered by someone to be all set for approval. People trying to get to that point are even worse off. The current backlog for people waiting to get a review has projects waiting with the needs review status for nearly a year — 11 months and five days. And of course the current project application review process, despite having gone through several iterations of improvement, still garners its share of complaints when running perfectly— and it still holds new contributors to a higher standard than we hold ourselves.
Finally, some unknown but large percentage of the two thousand projects marked "Closed (won't fix)" have been put in that state automatically by a robot due to lack of activity. If a contributor leaves an application in a "Needs work" state for a month, it is unceremoniously closed without warning. (In contrast, if we don't get around to reviewing or approving a project for months, nothing automatically happens in favor of the contributor, despite written guidelines for escalating ignored issues.) It will be fun to go through all these old issues and contact the contributors letting them know they can promote their sandboxes to full project (and then changing the issue to some other status, like works as designed, to mark it), but we can't do that until the overall process is fixed. The good news is we're closer than ever.
The current proposal looks solid, but it's suffering from inaction. The goals it outlines are excellent:
- We need to remove the gate to new contribution entirely - not just kick the can to a particular elevated role, or a specific limit on the # or kind of releases a new contributor is allowed.
- We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
- Follow-up: We need to find ways to preserve the value collaborative code review, through changes to Project Discovery to provide signals about code quality, and by providing incentives and credit for review.
I encourage anyone who cares about new people joining Drupal to work on the issues associated with this proposal, in particular the ones to allow non-git vetted users to promote sandbox projects to full project status and add a permission for creating stable releases, and grant to “git vetted” users. While my oft-stated preference is that any gates we put up must apply to all users, so we make sure the gates are bearable and don't forget about problems for months and years at a a time, moving the gate to a security review at a stable release has huge advantages of its own. It allows a new contributor to put their work out there without being blocked by anything. It allows a module to find its audience and have people invested in its particular functionality at the point of review, rather than have only volunteers who have no inherent stake in the functionality involved. It even lets a contributor decide whether a module has proven sufficiently useful to others to be worth going through security review.
We don't have that system yet though and we still have that huge backlog to get through. Helping other people follow the project application checklist is a great way to get better at making projects yourself— whether you have a dozen already, or don't have any yet. Just remember this is about helping applicants. To give further incentive to the review work, i've proposed including issue credits given to users in the Project Application review queue on profile pages and Marketplace rankings.
It's Rosh Hashanah, the Jewish new year, and the tradition is that we have ten days to make things right with any people we have wronged. Let's accept (again) that we as a community have wronged our potential new contributors, and make things right. Thanks.