High Psych2Go army, we have an urgent favor needed. Watch till the end to hear about it. Whether you're in a relationship or not, it takes two to tango. But what happens when your partner can't keep up with your rhythm? When the music comes to a stop, so does the love. It wasn't always like this, you tell yourself. But how do you know whether the feeling is temporary or if your love interest has already stopped trying? Here are eight signs your love is one-sided. One, it's been so long since the last time you've been happy. A relationship is not a fairy tale and we've heard the comments saying that every relationship takes work. But when you're in a one-sided relationship, it's more work than you deserve. Research suggests the more you laugh, the more it can relieve tension between both parties. Psychologists also discovered that achieving emotional regulation is important for duos to feel satisfied. Emotional regulation is the ability to respond to a situation with emotions that are appropriate and good for your well-being. But if your love interest focuses more on negativity instead of making room to look on the bright side, it brings the whole relationship down. Two, your love interest stonewalls you. Do you ever feel yourself getting all worked up but your person of interest walks away before a fight even starts? That is called stonewalling. Therapist John Gottman says that blocking off conversation can be just as toxic for a relationship as contempt. Because it keeps partners from addressing an underlying issue. When someone shuts you out, they also turn down a chance to work things out together. Three, your love interest frequently plays the victim card and you're tired of it. Do you face the opposite problem and deal with a person's defensive nature? Gottman says that it's dangerous for one individual to play the victim all the time. It means they avoid taking responsibility for their actions so if you're the one always apologizing, it allows them to get away with their faults. Four, your partner is all play but no sacrifice. Relationship scientists have discovered that making sacrifices is one of the many strategies people use to avoid conflict. But there has to be a balance achieved. If you're always the one bending your back and making the compromises, it leaves little to no room for you to receive the same benefits from your partner. Five, your partner doesn't respect your boundaries. Although it's nice to learn how to grow from using I and me statements to weep, it's never good to assume what the other person wants.  Dr. Lisa Firestone states that when this happens, it not only hurts you, but it undermines your strength and feelings for your partner. Six, you constantly justify their actions to your friends and family. Did you recently make up another lame excuse just to cover for them? However, your friends and family are not so easily fooled. That's the perk of being outside of a relationship. Outsiders can see things you and your partner overlook. You might get used to your partner canceling plans last minute, but your friends find it odd that they rarely make a presence. Although it's common to ditch friends to spend more time with your partner once you enter a relationship, staying in touch with them can actually bring perspectives you miss. Seven, they rarely return your favors or share their secrets with you. If they stop being kind to you, that's a big warning that the relationship is going downhill. Another key component relationships need is vulnerability. Research shows that healthy relationships entail a balance of trust and safety from both partners. No matter how open you are about your life, if your partner hesitates to tell you their own personal details, you're receiving the short end of the stick. Eight, they don't respond to your bids anymore. When you reach out to your partner for a connection, Dr. Gottman calls this a bid. For example, have you ever noticed something so eye-catching, like a good book or cute home accessory? You'd want to share the happy news with a loved one, right?  This also means they don't accept your invitation to feel close. Do you think you're in a one-sided relationship? Want to learn about what a good relationship looks like? We also made a video on 12 signs you're in a healthy relationship, so be sure to check it out. Thanks for watching. Hi, everyone. As you may have noticed, we don't post as often as we'd like anymore. We are low on funding as our expenses are exceeding our revenue. However, we want to keep making more content that help people learn about psychology and mental health. So we want you to be a part of that process. Starting today, we will have a donate button underneath our videos. You've probably seen it in some of your favorite channels already. But if you don't see the button, we've included a link in the video description. Our vision is to keep making psychology more accessible to everyone. We try to keep our videos concise and create open dialogues among the community. As a supporter, you will receive recognition for your support by having a cool side icon next to your username when you comment. This helps us recognize its hue and engage you more. On top of this, you will also receive a free copy of our Psych2Go e-book and occasional magazines every quarter. Just email in to myself when you've donated and I will send you the copies at tieatpsych2go.net. However, even if you cannot support us financially, we still totally understand. You can help us out by sharing this video. We still love you and will give you a free e-book if you mail in to let us know. There is no fixed term or shady things like that. You can also cancel your support at any time too. So there's absolutely no risk. We promise to use your funding wisely and for creating new videos that can help others. Let's make psychology more accessible for everyone.


Hi, everyone. My name is Beth Brogues and I'm a senior software engineer at Red Hat. I gained my Red Hat just three months ago when I moved over from IBM. And I'm excited to be here today at my first virtual DevCon. My tool today is titled, Consuming Open Source and Maintenance Perspective. As part of my role at Red Hat, I helped to maintain the Node.js runtime. I'm a Node.js technical steering committee member and particularly active within the Node.js release working group. This means a lot of my time is spent auditing the content for and producing releases of the Node.js runtime. And today I'd like to share some of my experiences and challenges as an open source maintainer and also showcase some of the work we're doing within the Node.js ecosystem to try and alleviate some of these challenges. I believe open source is backbone of the modern tech industry with major projects backing areas from IET to cloud orchestration. And I'd like to just start by showing some of my favorite open source projects. For example, did you know that there's open source for quantum computers? Quantum Qiskit is an open source software development kit for interacting and working with quantum computers at the level of pulses, circuits and application modules. And this is one of my favorite case studies. NASA consumes open source. One specific example is their use of Node.js. NASA uses Node.js to aggregate data from spacesuits. In 2013, an astronaut found himself in grave danger because water was leaking into his helmet. From this, NASA decided they needed a solution to aggregate all of the data from spacesuits to create an alerting information system. They chose Node.js to do this. You can read the full case study on the OpenJS Foundation. I think it's pretty cool that they're using open source in space. With open source being so prevalent in our industry, I probably don't need to convince you all of the benefits. But these are my key thoughts. First is that open source is open. This is good for access, accountability, transparency, etc. Open source is also community driven. Open source projects get input from a wider range of developers than what you would if you were developing internal cloud source software. This often leads to better solutions. And you also benefit from more eyes on the code. This means we've got more eyes to catch bugs and also hold code quality to a higher level. Open source also enables us to build a partner work of others. This means we can reuse already implemented low level APIs to save us time and save us having to reinvent low level technical implementation details. This means we can focus on our product and our business logic. For example, in the Node.js and JavaScript ecosystem, there's over 1.5 million modules on the NPM registry. So there's a high chance that one exists to make your life that little bit easier. And notice I've straight out free. Although open source can be free in terms of cost for usage, I wouldn't say it's free because there's a cost in terms of risk. And from an open source consumers perspective, I think these risks can be grouped into five key areas. Security, licenses, maintenance, breaking changes and compatibility. In terms of security, if you're consuming open source as dependencies of your project, you need to be equally concerned about any security issues or vulnerabilities in your open source dependencies as the code you've written yourself. You're responsible for all code you have deployed in production, not just the code you've written. As a consumer, you need to be aware of licenses. Particularly, you need to ensure the licenses of the open source you're consuming are compatible with your project and how you intend it to be distributed. I think maintenance is perhaps the biggest risk when consuming open source. If you're building a project atop of open source, you need to ensure the projects you're building upon continue to be maintained for the lifetime of your project. And then there's the risk of breaking changes. As your open source dependencies are likely to be maintained by someone else, there's a risk that the open source project may make a change that is not compatible with your usage. Compatibility is another concern. When choosing an open source project, you need to ensure that the project is and will continue to be compatible with the platforms, versions and runtime versions you intend to support in your own project. I think all of these risks are widely spoken about from a consumer's perspective and there are some known actions you can take to mitigate against some of these risks. For example, for security, there are a number of tools and commercial services that can alert you with known vulnerabilities in your open source dependencies. Some of these tools will go a step further and automatically update your dependencies for you or patch them when a fix is available. For licenses, many consumers will have a list of accepted license types that can be included in their projects. Consumers that build commercial projects will often have more stringent legal review processes in place to order any licenses of open source dependencies before they can be incorporated into their products. As a consumer, I believe there are two key ways in which you can reduce your risk in terms of maintenance and ensure your open source dependencies continue to be maintained. The first is to contribute back to your open source dependencies. This directly helps to ensure that your dependencies will continue to be maintained, but there are further benefits. By contributing back, you'll gain a greater understanding of the dependency code and also have a seat at the table in any future decisions. If you are unable to contribute time to help maintain your open source dependencies, the other way of doing so is to contribute financially. Many open source projects have funding schemes set up where you can donate funds to help support the maintainers of the projects. Again, as an open source consumer, you can reduce your risk of unexpected breaking changes by participating in the open source communities that you're depending on, in particular by commenting on issues and reviewing pull requests. You can also go a step further by producing some automation that will test your project against nightly versions of your open source dependencies. To reduce your risk in terms of compatibility, you should first ensure and selecting your open source dependencies that the platform and version support matrix of the open source projects aligns with the intentions of your own project. Also, if there's a niche platform that you want to ensure continued support for, again, contributing back via funding or participation is a good way to reduce the risk of the platform being dropped. So that's some risks and some mitigations from the consumer's point of view. I'd like to flip that now and take a look from the maintainers perspective. From the maintainers perspective, I think the key risks can be grouped into the same five areas. As an open source maintainer, in terms of security, the biggest challenges I experience are actually the expectations around security vulnerabilities. Many companies and organizations have defined windows in which they expect security vulnerabilities to be patched by, but these defined windows don't translate to open source projects. Many open source projects are people's hobby projects or side projects, and they may not have the capacity to produce a security fix at such short notice. Work bounty projects can actually be a challenge here because they incentivize security researchers to identify vulnerabilities in open source projects, but there's no incentive to help the maintainers patch these vulnerabilities. Again, this can lead to the maintainer being overwhelmed. As a maintainer, I need to ensure I have chosen an appropriate license for my open source project. This is not only to enforce how I wish the project to be distributed, it's also to protect myself from certain scenarios. If you are unsure on which licenses to choose, I tend to look at chooselicense.com, which gives a nice overview of some key license types. As a maintainer, it's probably not surprising that maintenance is a big concern for us. In particular, there may be expectations from consumers that we will deliver bug fixes that we will respond to feature requests. This is particularly a problem in the Node.js ecosystem. Many modules on NPM aside in hobby projects, and when these get super popular, a maintainer can be very quickly overwhelmed by the influx of issues and poor requests. There's also the issue that if at some point, I no longer have time to maintain the project, what will happen? I think a good example that demonstrates why both maintenance and security are key risks for maintainers is the event stream incident. This actually started as a social engineering attack. In this case, the maintainer of the MPM module no longer had time to dedicate to the project, so they put out a request for a new maintainer. The attacker appeared to be acting with faith and offered to take over maintenance of the module. After some period of time gaining trust, they published a malicious release that contained code to mine bitcoins. And I really think this highlights the need for some defined processes for handing over popular dependencies. I think this example also highlights that security and maintenance are risks for maintainers, just as they are for consumers. Raking changes are a concern for maintainers because they're the ones having to make the call on what changes are made. But the issue from the maintainers point of view is we may not know who is depending on our project. We may also have the problem that a bug from one user might be relied upon as a feature for another. And when we're making changes in our open source projects, there's not really an easy way to test the impact of our changes until after the release has gone out. The challenges our experience from a maintenance perspective in terms of compatibility are the expectation to support new and niche platforms and the expectation to maintain support for older platforms and runtimes. In some cases without help, we may not just have the capacity or access to actually support these platforms. I think the key overarching problem that all of these challenges stand from is the mismatch in expectations between the consumers and maintainers of open source projects. We've talked a lot about problems, but what about solutions? In the context of the NodeJS ecosystem, we've set up a working group to try and tackle some of these problems and come up with solutions. The NodeJS package maintenance team was established in 2018 as a team who wanted to focus on reducing the sources of friction to module ecosystem adoption, particularly in the enterprise. At the time, it was known that the highest level of comfort was with open source packages that were stable, had ongoing maintenance, predictable releases, and were easy to upgrade to new NodeJS versions. But unfortunately, at the time, it was also known that there were a number of packages that were broadly used in the NodeJS ecosystem that were no longer getting the basic maintenance they required. The package maintenance working group is comprised of members from a wide range of companies, from the likes of NPM, IBM and Red Hat, Netflix, and more. And we also have representation from both consumers and maintainers. And all of the risks and challenges I've mentioned today are areas that the NodeJS package maintenance team were exploring. The working group has several key aims, the first of which is to document best practices and processes for Node module maintainers to follow. Another aim of the working group is to promote sustainable and responsible consumption of open source Node modules. Another aim of the NodeJS package maintenance working group is to provide a space where module maintainers can ask for help. In the past, we've been approached by module maintainers who no longer have the capacity to maintain their modules. And we've successfully recruited a group of trusted maintainers to go in and help out. The package maintenance working group is aiming to define and document a comprehensive set of best practices for module maintainers, covering areas such as licensing, security, testing, versioning, and more. For each of these sections, we bring together the maintainers and our group to discuss and agree on the best practices. All of our documentation is available when the package maintenance repository, which is at github.com slash NodeJS slash package dash maintenance. For example, in terms of support, the NodeJS package maintenance working group is exploring whether we can expose support information in the package JSON file. For example, here we have defined a response type, which is time permitting, paid, which is false, and that would indicate whether there was any paid support available. And also what backing the project has is a hobby project or is the project backed by a corporate sponsor. We are also developing tooling to extract this information so that a user within NodeJS project would be able to run a command line tool and it would output all of the support information from their dependency tree. Our key next steps on this are to encourage adoption. This is a specific example by the NodeJS package maintenance working group of working on solutions to solve that mismatch in expectations between consumers and maintainers. Via the NodeJS package maintenance working group, a number of NodeJS module maintainers have gotten together to start building tools to help solve some of our common challenges. We're building these tools under an organization, on GitHub called PKGJS, which we describe as tools for package maintainers by package maintainers. An example of one of the tools that we've created under the PKGJS GitHub organization is the dependence tool. This tool helps module maintainers answer the question of who is depending on my project. So in this example, you can see with supplied tool with the package name Express and number five and sought by downloads. So what this will return is the five most downloaded projects that depend on the Express module. This information is really useful for open source maintainers as it allows maintainers to discover their downstream dependence. Once they have this information, they can bear these dependence in mind when making key decisions in their project, such as breaking changes. Again, this is all about bridging the communication and expectation gap between consumers and maintainers. So that's some of the work the NodeJS community are driving to try and alleviate some of these challenges. So I've shared some thoughts on the challenges of open source consumption from both a consumer and maintenance perspective. I've also introduced the NodeJS package maintenance working group. If anyone has a particular interest in following or joining the working group, please do reach out. Or if you'd just like to learn more, all of the NodeJS package maintenance meetings are streamed live to YouTube. If you'd like to see more of the discussions we're having and work we're doing. And although prevalent, these challenges are not unique to the NodeJS ecosystem. My expectation is that we'll start seeing similar discussions across run times and technologies with the potential to collaborate on solutions. My key little thoughts are that I believe as a consumer, the key way to reduce your risk of consuming open source is to contribute back to the open source projects that you're depending on. I also believe the key challenge as a container is to manage the expectations that your consumers have.