You may have noticed that it's been quiet here on Opensource.com lately. That's because there's a new project in the works, and while there aren't many specific details to announce yet, there's plenty to talk about. What better way to start than with the entire internet?

The internet, and top-level domains

You may know that the internet is a network. A network, by definition, is a group of connections. The term "internet" is in fact a portmanteau of "interconnected" and "network". The internet is a network of interconnected networks, and originally it consisted of two: The military network and the academic network. Once the internet got popular outside those two groups, it became apparent that different designations were needed to differentiate, say, a commercial entity from a charitable organization from a university or a governmental department.

These designations are called top-level domains (TLD). There are many available today, but for a long time there were only a handful. The original TLDs remain popular, and you probably know that when you go to, for instance, a .com address, you're visiting a commercial site, but when you visit a .org address you're going to a non-profit website.

Open source is a network

Open source can be many things. It can be commercial, it can be non-profit, it can be academic, it can be cultural. No matter what form it takes, though, it's always a network. Sometimes (but not always) it's a network of computers, but most importantly it's a network of people. Whether people are gathering at a conference or a pub or in an online chat room, open source is a community of people.

The website Opensource.com has been supported by a commercial entity for 12 years. But the people (that's you and me) that make up the Opensource.com community aren't commercial entities, we're people.

In one month, Opensource.com is going to resolve that bug. Stay tuned!

The community is hard at work on something new.

Over the past few years, virtual events have thrived. In-person events are back now, but it's important to keep in mind that virtual events didn't just come out of nowhere. Many of us were actually doing a lot of different online events even before they became popular. Many communities held hackathons, bug and issue triaging, webinars, and so on, as virtual events. They brought community members together for collaboration and education. Virtual events have improved since then, largely out of necessity, and I think we've all learned a lot. In this article, I consider how virtual and physical events can co-exist to render an improved event experience for everyone.

Costs and crowds

I don't think anyone wants to go back to the days when all events were happening on screens. But virtual events do have important advantages compared to in-person events. To begin with, it is relatively easy to start a virtual event as you often don't need much beyond meeting and streaming platforms. It can be as basic as live streaming from a video chat platform. This is especially useful for small communities that don't have a large events budget. In fact, a virtual event platform provides an opportunity to build an audience before you start making significant investments in in-person events.

The lower cost and logistical hurdles of virtual meetings don't just apply to the event organizer. It matters to attendees and community members too. A typical meetup is likely to last for 60 to 90 minutes. Is everyone always happy to commute 30 minutes each way to get to the meeting venue? A meetup in a virtual format can lower the participation barrier for attendees. I think this is one of the reasons that many meetups are continuing in virtual formats today.

The cost of doing virtual events is much lower, so there's low-risk of experimenting with different content, format, target audiences, and so on. Even if a new event isn't a huge success, you won't have to invest a large budget on the venue, equipment, people, travel, and so on. And you're able to get some valuable learning from the event no matter what.

Practical events

In addition, there are some activities that are just well-suited for virtual events. Things like documentation and bug triaging are crucial in open source communities. Despite this most people see them more like chores that they'd rather avoid. Why not have a short one to two day window where community members come together online so they can work on these chores together while supporting each other?

Hybrid events

Many events are going hybrid now, with both in-person and virtual components. By hybrid, I don't mean just broadcasting in-person sessions from conference facilities. Many have separate tracks for in-person and virtual participants. FOSDEM 2023 is a great example of a hybrid event, with separate online rooms.

Some utilize virtual tracks for "Day 0" events (orientation, project team meetings, meetups, and so on). This way, people who aren't able to travel to the in-person conference can still participate in the earliest events. By having a separate virtual track, you can potentially reduce the total length of the in-person conference. This means people don't have to be away from home as long as a 100% in-person event.

The dos and don'ts

Here are some tips based on my experience of attending and organizing virtual events.

• DON'T have the same structure as in-person events. When you have an event online, you wouldn't want to ask the audience to sit through a full day of presentations. It's difficult for most people to stare at their screens for a long period of time. If you have more than four hours of content, consider spreading the event over a few days so that attendees only need to sit through a maximum of a couple of hours of presentations each day. You also don't always need to add breaks between sessions in virtual events because people aren't moving to different rooms. As a matter of fact, by hot switching to the next session, you're less likely to lose attendees between presentations.

• DON'T put a wall around the content after the event. I recently registered and attended an event and was told that slides and recordings would be available a few weeks after the event. When I returned to the event page a few weeks later, it asked me to register with my email address to get access to the content! I understand people's desire to collect leads. But if people had to register for the event already, or the event was live-streamed, it's not appropriate to ask them to share their contact information. Instead, make the content accessible to anyone.

• DON'T force synchronous participation from attendees. One of the key benefits of virtual events is that it's easier for everyone to attend or participate. If a person cannot watch a presentation live, provide ways for them to interact with presenters and other attendees asynchronously.

• DO make content available prior to events. Online events make it easier for community members to participate asynchronously. Things like publishing slides or Q&A pages ahead of time allow attendees to review content and post questions that presenters can address during and after the session. Also, if you're doing a hands-on workshop, publishing a prep guide before the event allows attendees to set up their environment so that it's easier to follow along during the presentation and play around in their sandbox.

• DO have presenters available for asynchronous Q&A sessions. Some of the virtual events I enjoyed had dedicated Q&A channels (Mattermost or Discourse are great open source options) where you could interact with presenters well after their session ended. At an in-person conference, you're often limited to a 10 or 15 minute break after a session to talk to the presenter. Virtual events allow you to have a Q&A channel available for a few days after the event.  This let's both synchronous and asynchronous attendees communicate with presenters.

Best of both worlds

I'm definitely glad that in-person events are back and I'm able to see my open source friends again in real life. However, I don't think we need to completely put virtual events behind us. In particular, hybrid events with "virtual tracks" can make events accessible to more community members and help you reach a wider audience. I think society has learned some important lessons, so let's put them to good use.

Create the perfect blend of virtual and in-person events.

Are you interested in leveraging Markdown for online content without any website setup or build process? How about seamlessly embedding constraint-free Markdown or HTML into multiple platforms (such as a content management system or learning management system)? The open source project Docsify-This, built with Docsify.js, provides an easy way to publish, share, and reuse Markdown content.

[ Get the Markdown cheat sheet ]

What is Docsify-This?

With Docsify-This, you can instantly turn any publicly available Markdown file into a responsive standalone web page. You can also link multiple Markdown files to create a simple website. Designers can alter the visual appearance of displayed pages with the point-and-click Web Page Builder interface or URL parameters. You can also use a set of provided Markdown CSS classes when creating your own Markdown content. In addition, if you use Codeberg or GitHub to store your Markdown files, an Edit this Page link can be automatically provided for each page to support collaborative authoring.

It's open source, so you can host a Docsify-This instance using your own custom domain without the risk of platform lock-in.

Use the Docsify-This Web Page Builder

To use the Web Page Builder, open a browser and navigate to the Docsify-This website or your local instance. In the Web Page Builder section, enter the URL of a Markdown file in a public repo of Codeberg or GitHub (other Git hosts can also be used via Docsify-This URL parameters but not in the Web Page Builder), and then click the Publish as Standalone Web Page button.

Image by:

(Paul Hibbitts, CC BY-A 4.0)

The Markdown file is rendered as a standalone web page with a URL you can copy and share. Here's an example URL:

https://docsify-this.net/?basePath=https://raw.githubusercontent.com/hibbitts-design/docsify-this-one-page-article/main&homepage=home.md

Docsify-This rendered web pages are perfect for embedding, with the ability to visually style Docsify-This pages to the destination platform.

Image by:

(Paul Hibbitts, CC BY-A 4.0)

Render other files in the same repository

You can render other Markdown files in the same repository by directly editing the Docsify-This URL parameter homepage. For example:

https://docsify-this.net/?basePath=https://raw.githubusercontent.com/hibbitts-design/docsify-this-one-page-article/main&homepage=anotherfile.md

Modify the web page's appearance

You can change the appearance of any Markdown file displayed in Docsify-This by using URL parameters. For example, font-family, font-size, link-color, and line-height are all common CSS attributes and are valid parameters for Docsify-This:

https://docsify-this.net/?basePath=https://raw.githubusercontent.com/hibbitts-design/docsify-this-one-page-article/main&homepage=home.md&font-family=Open%20Sans,sans-serif

You can also alter the visual appearance using a set of special Markdown CSS classes. For example, you can add the button class to a link:

[Required Reading Quiz due Jun 4th](https://canvas.sfu.ca/courses/44038/quizzes/166553 ':class=button')  

This produces a button image instead of just a text link:

Image by:

(Paul Hibbitts, CC BY-A 4.0)

In addition to the Markdown CSS classes supported by Docsify-This, you can define your own custom classes within your displayed Markdown files. For example:

<style>
.markdown-section .mybutton, .markdown-section .mybutton:hover {
  cursor: pointer;
  color: #CC0000;
  height: auto;
  display: inline-block;
  border: 2px solid #CC0000;
  border-radius: 4rem;
  margin: 2px 0px 2px 0px;
  padding: 8px 18px 8px 18px;
  line-height: 1.2rem;
  background-color: white;
  font-family: -apple-system, "Segoe UI", "Helvetica Neue", sans-serif;
  font-weight: bold;
  text-decoration: none;
}
</style>

[Custom CSS Class Button](# ':class=mybutton')

Produces this:

Image by:

(Paul Hibbitts, CC BY-A 4.0)

Include HTML snippets

As supported by standard Markdown, you can include HTML snippets. This allows you to add layout elements to your HTML render. For example:

<div class="row">
<div class="column">

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

</div>
<div class="column">

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

</div>
</div>

Embed Docsify-This as an iFrame

You can embed Docsify-This web pages using an iFrame in almost any platform. You can also use URL parameters to ensure your embedded content matches your destination platform:

<p><iframe style="overflow: hidden; border: 0px #ffffff none; margin-top: -26px; background: #ffffff;" src="https://docsify-this.net/?basePath=https://raw.githubusercontent.com/paulhibbitts/cmpt-363-222-pages/main&homepage=home.md&font-family=Lato%20Extended,Lato,Helvetica%20Neue,Helvetica,Arial,sans-serif&font-size=1&hide-credits=true" width="800px" height="950px" allowfullscreen="allowfullscreen"></iframe></p>

Image by:

(Paul Hibbitts, CC BY-A 4.0)

Embed Docsify-This with an external URL

In certain learning management systems (LMS), including the open source Moodle and even the proprietary Canvas, you can link external web pages to a course navigation menu and sometimes more. For example, you can use the Redirect Tool in Canvas to display Docsify-This web pages.

url=https://docsify-this.net/?basePath=https://raw.githubusercontent.com/paulhibbitts/cmpt-363-222-pages/main&homepage=resources.md&edit-link=https://github.com/paulhibbitts/cmpt-363-222-pages/blob/main/resources.md&font-family=Lato%20Extended,Lato,Helvetica%20Neue, Helvetica,Arial,sans-serif&font-size=1&hide-credits=true

Integrate Docsify-This and Git

To fully leverage the benefits of version control and potentially collaboration using an optional Edit this Page link, store your Docsify-This Markdown pages in a Git repository on either Codeberg or GitHub. Several open source tools provide a graphical interface for Git, including GitHub Desktop (recently released as open source), Git-Cola, and SparkleShare. The text editors VSCode and Pulsar Edit (formerly Atom.io) both feature Git integration, too.

[ Get the Git tips and tricks eBook ]

Markdown publishing made easy

The benefits of Markdown-based publishing are available to everyone, thanks to Docsify. And thanks to Docsify-This, it's easier than ever. Try it out at the Docsify-This website.

This open source tool makes it easier than ever to convert Markdown to web pages.

Recently, I was asked by a friend and colleague if I were interested in speaking together at a conference. I was pleasantly surprised because I hadn't contributed much to the project they were presenting, but I expressed interest. We met to discuss the presentation, and that's when I learned the real reason I was asked to participate: The conference's diversity, equity, and inclusion (DEI) initiatives required there to be at least one speaker that does not identify as a man. I was offended; it felt like I was approached only because of my gender, not based on merit.

My friend assured me that wasn't the only reason I'd been asked. They needed new contributors to the project because there was a lot of work to be done, and they were hoping I could help fill that gap.

[ Want to create your own event? Read the 10-step guide for a successful hackathon ]

I gave it some thought and tried to understand why the DEI initiatives were in place.  I also thought about the other side of the coin, where the people who wanted to present couldn't, unless they found someone from a minority group to present alongside them.

As I thought about the bigger picture and the benefits this opportunity would bring to me, I decided to forego my ego being hurt. Once I let go of feeling offended, I realized that I was also feeling very uncomfortable presenting something that I hadn't contributed directly to. My ethics didn't agree with that. How could I possibly step onto a stage and act as the face of something I hadn't worked on?

Resolving to help more

I did some research on the project. The technology was not totally alien to me, and I had a good grasp of the fundamentals it was trying to achieve. In fact, its overall goal made me feel excited to contribute. If done well, it would be super useful to users.

I made a resolution that I would go ahead with this speaking opportunity only if I got the opportunity to give back to the community tenfold and become a key contributor. My friend was more than willing to help me on that journey.

With that resolve, we submitted our talk. My co-presenters were supportive and made me feel welcome. They said that as long as I was interested and had a passion for the project, nothing else mattered.

[ Also read How I returned to open source after facing grief ]

Participating in the conference was a huge opportunity, and it had such a positive impact on me. I met a lot of experienced people across the open source community and I felt inspired! I learned a lot of new things from the people and the various panels, sessions, and discussions at the conference. Our presentation went well, and I consider giving a talk at such a big conference quite an achievement.

However, once the conference was over the guilt started kicking in.

Guilt as a motivator

I felt like I owed the community and the people who had given me this chance. I wanted to focus on the promise I'd made, but it was hard with other higher-priority things getting in the way. Whenever I deviated from my plan, the guilt kept me on track. It reminded me that I had to give back to the community that had given me such a good opportunity. After a few months of struggling and juggling, I can proudly say that I didn't give up. Today, I'm an active contributor to that project.

I love the challenges it presents, and I enjoy solving some of the key issues in the project's area. I also have been able to take the lead in implementing this upstream project in our downstream ecosystem. As icing on the cake, I was again invited to present with the team and give the community updates for the project. This time, it was not because of a DEI initiative, as the ratio was already balanced.

Feeling guilt isn't so bad after all!

I'm glad that I took the opportunity, and I'm glad it turned out to be a win-win situation for everyone involved. If I hadn't been approached about being a co-presenter, I probably would have never gotten involved in this project, and that would have been such a miss! I'm grateful to the people who gave me this chance and supported me.

I'm probably not the only woman who has faced this. I want to tell all the women out there if such an opportunity presents itself, there's no need to feel guilt, or that you "owe" anyone or any kind of pressure. If you feel such pressure, turn that emotion into a weapon and do good with it! I encourage you to take the opportunity if it will benefit you and make the most out of it. Later on, if you can do the same for another person and uplift them, that’s how you can really pay back to the community. After all, this is what open source community is all about. It's as much about the people as is about the technology being built!

[ Ready to level up your communication skills? Get advice from IT leaders. Download 10 resources to make you a better communicator. ]

Guilt is usually considered a negative emotion, but by steering it well, you can achieve surprising success.