In the summer of 2017, a lively open source licensing debate was happening: the React framework had become one of the most popular frameworks in existence, but was React’s open source license open enough for developers to trust it? Developers were worried whether they could use it without legal repercussions from Facebook, the primary maintainers of React.

The complexity arose because, while the React project adopted the popular and well-known BSD free software license, they also adopted an additional, unusual patent grant which worried developers.

Facebook’s “BSD+Patents” license had been a part of React for some time, but high-profile projects did not begin to consider removing React until the Apache Software Foundation labeled it a Category X license, or license that may not be included within Apache products. This, followed by Automattic (the primary company behind WordPress) deciding to pull React from its open source projects, ultimately lead to Facebook dropping the patent clause and using the standard MIT license — not only for React, but a number of other open source projects they maintain, as well.

There still seems to be a lot of lingering questions around the debate, even though it’s been resolved as a decisive win for the open source community. For example, why did the patent clause exist in the first place? Facebook’s Adam Wolff explained the reasoning, but understanding that explanation requires first knowing why companies need patent clauses in the first place and what does this kind of patent protection even mean?

Facebook didn’t invent the idea of patent protection clauses, but given their access to nearly infinite lawyers and money and being stewards of an increasingly popular front-end framework, it was natural that React users without that access and money would worry about the legal risks. This risk is heightened by many people’s tendency to ignore licenses and terms of service agreements until someone points out on social media what we may have actually agreed to.

Instead of speculating, I reached out to Gary Pendergast, an engineer at Automattic.

Gary is part of the WordPress core dev community and works on some of the projects where Automattic initially decided to pull React. He offered some insight on why licensing is important for engineers, and how licenses impact his work, part of which powers over 25% of domains on the Web.

How would you explain licensing and its importance to a developer who is either just learning to code or has not been involved with the open source community?

GP: The open source community can be a great place to learn to code, there are countless examples, free code libraries, and wonderful, helpful people to get you going. But all of that is predicated on the idea of giving back some of what you get out.

Writing code is a creative process, in the same way that writing a story, or recording music is, so the code you write is copyrighted to you, so people need to ask for your explicit permission to use that code. Some open source licenses implement an idea called “copyleft”, which allows you to maintain the copyright, but you give everyone permission to freely use the software you wrote. The only reason you can use all of those code libraries is because they’re under an open source license — someone before you has joined the open source community, learned how to do something cool, and released it back freely, in a way that benefits everyone.

So, licensing is important, because it lets you be the person who helps those who’ll come after you. There are a range of established open source licenses that will share the things you create in whichever way you’re comfortable with.

What projects are you working on at Automattic that are affected by the licensing of React?

GP: I’m fortunate enough to be sponsored full-time to contribute to the open source community — while I’m employed by Automattic, my work is entirely focussed on building cool things to give away for free.

Right now, I’m working on a project called Gutenberg, which, at the core of it, is a big re-architecture of how WordPress manages content in a website. The first part of that involves rewriting WordPress’ post editor into a modern JavaScript app, which uses React to render the interface. That’s the part which was seriously affected by React’s license.

Why would React’s license matter on a project that uses React?

GP: One thing you will find in the open source community is that people get very passionate about software licenses. It’s not really surprising, the freedoms we enjoy in open source rely heavily on those licenses, people are naturally going to be protective of those freedoms.

In the case of React’s license, the patent grant was the thing that caused the most concern, or at least, one particular clause in the grant, which allowed Facebook to revoke the patent grant under some limited circumstances. There were some interesting arguments suggesting that this clause had very little practical enforceability, and others arguing that the patent grant was a net benefit, but the concern wasn’t really about whether this clause could be enforced. Most of the disagreement was about the “vibe” of the thing — this clause felt a bit like Facebook was trying to get the benefits of the open source community, while avoiding giving back.

For a project using React, if we were to assume a worst case interpretation of the patent grant, React could easily be seen as a trojan horse — React is a wonderful tool to use, but it potentially gave Facebook an unfair way to attack competitors. If you were a startup that held software patents, and Facebook violated those patents, then suing them for patent violation could result in the React patent grant being revoked, even if the original patent violation had nothing to do with React. While this is a fairly unlikely scenario, the fact that it was possible made people uncomfortable.

React  up until they changed it to MIT. Why did it take this long for Automattic to take this stance?

GP: Automattic has been using React for years on other projects. For example, Calypso is an open source project, using React, that powers the interface you see when you manage your site on WordPress.com. Our legal team evaluated the patent grant in the React license at the time, and decided that it wasn’t a concern for the company. Partially because of the questionable enforceability of it, but primarily because Automattic doesn’t collect software patents, so is never going to be in a position to be suing Facebook for patent infringement.

In Gutenberg, however, there were different priorities, particularly as this code would be rolled out to over a quarter of the web. The WordPress Core team didn’t feel that we could make the same decision for the entire WordPress world.

What would the consequences be of pulling React out of those projects if Facebook were to hold their stance on keeping the patent clause? How significantly would this have delayed releases of those projects?

GP: For Gutenberg, the impact wouldn’t have been huge, though that’s mostly because it’s architected with situations like this in mind. Over the years, we’ve found that WordPress often outlives the libraries it depends on, so we usually spend time on ensuring we can swap them out at a later date if we need to. In this case, components in Gutenberg don’t use React directly, they talk to a thin wrapper around it, so the task of replacing React would’ve been relatively simple, particularly if we were to replace it with a React-compatible framework, such as Preact.

The Calypso project doesn’t have that abstraction layer, so it would have taken significantly more effort, though it’s an effort we were willing to make. From a strictly business viewpoint, Calypso has no need to maintain compatibility with WordPress, so didn’t necessarily need to have chunks of it rewritten. Part of being a good citizen of the open source community is to play nicely with others, however, even if it requires effort on your part. So, we would’ve taken the time to do that, because it’s the right thing to do.

Do you consider this the best outcome for this situation? Do you think MIT was the best choice, given how many licenses are out there?

GP: I’m happy with the outcome here, React moving to the MIT license means that it can easily be used in any open source project, without concern that React’s license may not be compatible with your particular open source license.

The one down side of the MIT license is that it doesn’t include a patent grant at all. The best possible outcome probably would’ve been to use a standard open source license like Apache 2.0, which includes the patent grant, but heavily restricts the circumstances under which that grant can be revoked. Similarly, a better outcome may’ve been if the React patent grant was changed to remove (or reduce) the revocation clause. There’s basically no practical difference, however. Even assuming Facebook hold any patents on React, it would be an extremely poor business decision for them to try enforcing those patents.

As more companies become stewards of widely used open source projects, these important discussions around licenses will continue, as will the need for new developers to learn about the impact of open source licensing. The biggest takeaway from this whole thing though, is the importance of considering the impact of your choice of license on downstream users. Even with the best of intentions, we saw in this example, the clear need to balance your own interests with the needs of others who you’re intending to help by making your project open source.

Those of us on the Glitch team have thought about these issues extensively. Recently, we launched an update to the editor allowing the addition of an open source license to a project with just a click. Software licenses are typically represented as text or Markdown files in a project, so they were always able to be added manually, but this update makes the process even simpler.

Besides making the process more efficient, it is our way of facilitating the education of licensing and its importance to software development—especially open source software. We hope this will help the Glitch community not only be more knowledgeable and involved in the open source community, but in the discussions around open source licensing that are sure to continue in the future.

If you’d like to learn more about software licensing, read our post ‘Why Add a License to your Open Source Project?’

Over React? Open source licensing, Facebook, WordPress, and patents

No company quite embraces radical transparency like Buffer. Employee salaries, diversity workforce numbers, and overall revenue are just a few of the metrics that are available to the public. Even the code used to power Buffer is open source and available on GitHub!

We are discussing transparency this week, so we thought it would be great to talk with Buffer’s Director of People, Courtney Seiter, to learn about the long-term impact of radical transparency on the company. She also talks about the creation of Buffer’s Transparency Dashboard, and gives some great tips for companies interested in adopting transparency.

I was a Buffer customer way back in the day, maybe like six years ago, and it really served a purpose for me. I was sort of a late night RSS feed reader, and nobody wants to read all your content at midnight, so Buffer was the solution for me to be able to share things at the right time to engage with an audience.

And then, the more I learned about Buffer, I gradually started to gravitate from just the product to learning more about the culture. And when I saw the culture slide deck of Buffer’s ten values, I really was just blown away. It’s kind of the dream that you never imagine could be real — that you could work for a company that thinks and cares about these things and continuously works on them. So yeah, I was kind of a fangirl early on.

Diverse, I would say? I’ve done a lot of different things at Buffer. I started out in a marketing capacity, and then as we started to grow, I moved into a diversity and inclusion focused role, and that morphed into a people operations role. And all along the way, I was pretty amazed and delighted to see that the values that are written down are not just words on paper; they really are something that we talk about and think about and try to evolve and iterate on. They are something that is always on the minds of pretty much everybody that works at Buffer, and that makes it a pretty special place to work for me.

Oh my gosh, so many impacts. I’ll start internally.

One huge benefit is that the team has full context of everything that’s going on at any time. As long as we all share information, what’s going on in our email, what’s going on in our projects, or what’s going on in Slack, that gives everyone full context to make connections we might otherwise have missed to put together ideas that may have not happened otherwise, and to have the full trust in the team because they understand the full context of what’s going on.

Externally, there are also a lot of great benefits. For one, we learn. We learn so much faster than if we were to keep things to ourselves, so if we iterate on our salary formula and we put that out there to the world, tons of smart people in our audience are going to come to us and say, “How did you do this? Did you think about this? I see a potential future challenge here.” We’re able to gather all that information that’s sort of “wisdom of the crowd” information that otherwise would have been entirely lost to us. Entirely missing.

We also feel like we do what we can to promote the startup environment and community. It’s almost like open source code. We add to the world of knowledge around how startups do things, how we build, how we pay people, how we provide benefits, how we travel, and how we work as a remote team. All that stuff, we hope, can help another company, help another person launch their idea and get something off the ground, and have them do a little bit less research than maybe we had to do. It’s sort of a net benefit for the world, we hope.

That’s a good question. Most folks automatically think it’s going to be something like jealousy around knowing what another co-worker makes. Really, the only challenge we have found with transparency is that it takes time to do it. You really have to set aside time and keep making it a priority and keep making it something that you communicate.

It’s real easy to have a meeting and take the outcomes and the action items and execute on them. It’s one extra step to say, “Let me write up these notes and share them with the whole team so everyone’s aware of what’s going on.” Or, “Let me post a recording of this call somewhere where everyone can see it.” It’s something we have to recommit to often and it’s something that can easily slip by when you get really busy, but it’s something that we have seen enough gains and benefits from that we always take that extra time and energy to do it because it’s that important to us.

You know, we haven’t really seen that. Generally our investors, like folks who have chosen to be part of this journey with us, did so with eyes open knowing what we do and how we do it, and most of them feel pretty comfortable and aligned with our mission — this is the kind of company that we have set out to be.

Now often sometimes we will see someone look at the information on the dashboard, particularly around revenues and take to their own blog and say, “I see Buffer’s MRR dipping and this is what I would do about it,” and we love that. We read those with such interest and often we’ll reach out to those people. It’s that “wisdom of the crowd” thing again coming back; sharing that information just means more minds on the job.

We created the dashboard in partnership with Baremetrics. They are a like-minded company, wanted to do something fun and we were already keeping these records internally anyway. I think we just asked ourselves “Could it work? Could it work to do this?” We iterated on it a little bit in terms of what information we felt comfortable showing — not from our perspective, but from a customer’s perspective. We have signed up for transparency; but our customers — many have followed along with what we’re doing and feel really aligned with it , and many just want to have a service to Buffer their social media posts. We always want to be respectful of their privacy even as we do these crazy things with our own sort of transparency efforts. That was the only sticking point there: making sure that we were sharing as much as we could while protecting our individual customer’s privacy. Once we did that, we were able to launch it and I think Baremetrics has done that with a couple of other companies as well.

That’s definitely a situation that we had never encountered before and I sincerely hope we never encounter again. The tough thing about transparency is figuring out where the line is between what to share because you can and what to share because you should.

A lot of times, there’s a debate on if we should share something that will really freak out the team if there’s nothing they can do about it. Is that within our value of transparency? Or do we try and act on it as best we can and then share with them the outcome of what happened? That’s what we ended up choosing in this case — the latter option. We didn’t share the entire evolving situation because there’s not a lot we can do to get the information if our runway is very, very short and things are in sort of a panic state. It’s not going to do everyone a lot of good to hear that and not be able to act on it.

What we ended up doing was sharing, in retrospect, that the runway was short, and this is what we did about it. “It was a terrible, terrible day. A terrible moment. We don’t want it to ever happen again. Here are the things we’re doing to make sure it doesn’t happen again.” So that’s a judgement call, right? Maybe our team would have wanted to know every step of the way. Maybe they would have wanted to be involved. Maybe they would have had great ideas that we didn’t get to hear and didn’t get to act on because we chose to shield that information from them and only share it when it was a done deal. It’s an evolving conversation. It’s something we are always talking about. It’s something that we want to own up to when we don’t feel like we have done it the best that we could and we want to keep learning from those situations.

It’s kind of hard to say what the takeaways are. In terms of sharing bad news with the team, I think the team has expressed with us that they want to be all-in. Like, Buffer is known for this: its transparency. Everyone knows everything, that’s what they sign up for, they can handle it. So in future bad news situations, which I sure hope are few and far between, we will probably try and give everyone information much closer to the time that it happens rather than wait.

I think we get a lot more people interested in Buffer because of transparency. One benefit of transparency that I didn’t mention, and that we didn’t set out to achieve, was that of marketing success. We never said “if we share salaries, all these publications are going to be knocking on our door.” It was a natural side effect of it; people were just interested in them. As a result of that, more folks heard about Buffer and heard about Buffer’s culture than maybe they would have otherwise. When we made salaries transparent, for the next open job role, we had double the number of applicants for it. I think that’s a pretty strong sign that folks feel aligned with what we’re up to.

I think so. It kind of lets you know what you’re in for. If you’re a person who is very private and this idea is frightening and terrible to you, Buffer is probably going to be a mismatch. If you’re someone who’s open to that idea, and you don’t have to be entirely gung-ho, but open to learning more and learning about the philosophy behind it and why we see the benefit of it, then Buffer could be a great spot for you.

I would say small steps are fine, you know? It would be tough to go from a very traditional organization that holds things quite close to the vest and then just one day open up everything. You can take steps in between. If you want to be more open about salaries, you don’t have to share them with the world. You don’t have to post them to the Internet with people’s names and cities. You can share bands of salaries internally, and if that goes okay and people aren’t freaking out, maybe you can share actual salaries internally. If that goes really well you can think about the next step, but break it up into smaller pieces. Radical transparency is not something that happens overnight. It’s the result of many, many small decisions over many, many years.

Many companies are adopting levels of radical transparency, including us here at Fog Creek. 

Buffer: What it’s really like being radically transparent

Most people don’t add a license to their code projects. In 2013 for example, only ~15% of projects on GitHub had one.

There are a few explanations for this. Some suggest developers are pushing back against what they see as a “permission culture”, others blame platforms like GitHub for initially not taking licensing seriously enough (it was 5 years before they added a license picker for example). But I think James Governor perhaps gets closest to the truth in this tweet:

Whatever the reason, it creates a real problem which actually could stop your code from being used by others. Probably, the exact opposite of what you intended!

Just sharing your code publicly on GitHub, Glitch or elsewhere doesn’t mean it can be used. Actually, any code that doesn’t specifically have a license should be considered “all rights reserved” by its author. The author could assert their copyright at any time, and demand you stop using it. So not knowing whether your shared code is meant to be used due to lack of a license could be why your projects don’t have more stars, forks or remixes. As Jeff Atwood puts it “a proper software license is a necessary evil for any code you plan to release to the public.”

But picking a license is hard?! I hear your cry. And you’re right, in the past licensing was tricky. There are lots of them, and they included legalese that made them difficult to understand.

But thankfully, there’s been a push in recent years to make licensing more accessible with sites like the Open Source Guide and Choose A License (both GitHub initiatives) making understanding them and choosing one a lot easier.

Which to choose typically comes down to how comfortable you are with other people:

Making decisions about what others can do with it

But a number of de facto standards have emerged for different use-cases. Like if you want your project to be used as a dependency in other projects then it’s probably best to use the most popular license in that community. For Node projects for example, MIT is the most frequently used license for npm libraries. If you want your project to appeal to large businesses, then they’ll probably want an express patent license like Apache 2.0. If you want your project to appeal to those who don’t want their contributions to be used in closed source software then GPLv3 and AGPLv3 are good candidates. And if you’re contributing to an existing project, it’s often expected that you’ll release your modified versions under the same license as the original work.

As a result of these common scenarios, the vast majority of software now use either a permissive license, like an MIT, BSD, or Apache license, or a strong copyleft one such as GPL v2 or GPL v3. Sticking with one of these standardized licenses makes it easier for others to know what they can and can’t do with your code. But if you’re releasing an open-source project for work, then it’s always good to check in with your legal team.

If good fences make good neighbors, then a good license certainly makes for a good project. It backs up the appearance of permission you've given folks in sharing your project publicly by expressly giving it in a way you’re happy with. That way, everyone knows where they stand.

It’s such an important aspect, we've made the ability to add a license (and a Code of Conduct) to your project a one-click thing in Glitch. For us, having more Glitch projects explicitly declare their licenses increases the odds that people will be able to easily work together and share their creations. So we've added licenses to all our sample projects too.

So the next time you’re creating a project on Glitch, be a good neighbor and add a license to it.

Why Add a License to your Open Source Project?

Successful software development projects rely on transparency. It’s such a key part of the software development process, that it’s one of the 3 pillars of the Scrum methodology.

But whatever your team’s workflow, the efficacy of decisions made throughout the creation of software depends upon transparency in all aspects, from the goals of the project, to the resources required to deliver those goals, and progress throughout.

However, that’s all good in theory. But how do you deliver transparency in an ever changing environment, with a team of people all with differing agendas and motivations, and often times with an organization’s changing priorities and deadlines?

One way is with a Daily Standup. A brief, time-boxed event for the Development Team held at the same time each day. The Development Team discusses the work completed since the last stand up, what they aim to get done by the next one, and highlight any problems that stand in their way. This is typically done by each member providing short answers to the following questions:

When done right they can improve communication, identify blockers to progress and encourage quick decisions to resolve them as well as improve each member’s understanding of the project.

But it’s important to do them well. They can break down when:

Folks show up late, or skip the standup altogether

Some people don’t say much or their updates are too vague

Others talk too much, providing unnecessary detail or go off on tangents

People aren’t prepared for the standup, they can’t remember what they worked on or what they planned to do

So if you’re going to do them, you need to trust the process and follow it. A great way of building in that structure, in both remote and co-located teams, is with a tool like Jell. Jell is specifically designed to help development teams carry out more effective daily stand ups. And better yet, it integrates directly with Manuscript.

We stress the importance of using the right tools for the job. And when it comes to daily stands, Jell could be that tool for you. You can prompt people for updates at a specified time, by email or even within tools like Slack. People can see what it is they planned to get done, helping them stay on track. And by having them recorded in text form, it helps keep them brief and makes it easier to compare what was planned and what was achieved. Having it integrated with Manuscript is a bonus too, as links to cases give your team members all the context they need to understand the task, so everyone is on the same page.

After signing up, head to your organization settings and select Manuscript under connected apps.

Then while making a standup update, you can add Manuscript cases. Out of the box, your team will be able to search Manuscript cases from within Jell itself. And you can even limit teams to specific Manuscript projects.

Once a standup is complete, you can review what everyone’s working on in Jell.

Of course, you can’t just throw some software at it and expect to fix all problems. You still need to manage the updates by picking up on incomplete information, by paying attention to what is really being said (or not said!) and clarify differences between planned and actual results.

But, by running a Daily Standup with a tool like Jell with Manuscript you can help provide shared accountability toward achieving goals and promote self-organization among your team. Ultimately, this can help deliver transparency throughout the creation process of your software development projects.

Want to Craft Great Software? Stand Up for Transparency

Decades ago, discussions about salaries and compensation in the workplace were seen as taboo. But now, more and more companies are being open and transparent about these topics, particularly in the tech industry.

Here at Fog Creek Software, salary transparency has been part of our evolution as a company since the very beginning.

“In the interest of fairness, Fog Creek’s compensation policy is open, public, simple, and accountable,” says founder Joel Spolsky in a blog post from August 2000.

According to Spolsky, some companies consider revealing your salary a fireable offense. “We feel that in the long run, this can only hurt us through negative morale, high turnover, and destructive office politics.”

Anil Dash, current CEO of Fog Creek remembers when he first read Joel’s thoughts on compensation.

“Like a lot of people in tech, at that time I hadn’t studied much about workers’ rights or the history of labor, so I didn’t know what a great role predictable compensation paid in making work more fair. Joel being Joel, he couched it in the context that many coders like rational, predictable systems, which is also often true! And I think from both standpoints it was about making workers happy and reducing some of the stress and tension around compensation and salaries, which are some of the most fraught conversations anyone can have at work.”

As companies grow and change over the years, so do their policies. Fog Creek is no exception here, and implementing salary transparency over the years has been a continual process. Jessica Moy, Head of People and Culture at Fog Creek Software, cites the general discussion and changes in tech workplace culture over the past few years as a reason for keeping salary transparency top of mind.

“A huge topic in the workplace in general is why don’t we know what other people make, why it’s a bad thing, and how [salary transparency] can help, especially when we’re thinking about the general wage gap between minorities, women, and other underrepresented groups. With that in mind, Fog Creek wanted to really embrace diversity and inclusion, and realized that a really key part of that was to make salary transparency a priority. It’s definitely all related.”

“As the company grew,” notes Dash, “new roles were added that didn’t neatly fit into the technical orientation of Joel’s original salary ladder. We added Sales people who expected standard compensation based on their sales volume, and administrative or organizational roles that weren’t going to be advancing in programming skills the way that coders would. As these new roles expanded, salary transparency sort of got left behind, to the point where half the company didn’t have a ladder to look at.”

We knew that these differences between roles weren’t good enough.

“Fog Creek has always been at the forefront of pushing what workplaces can and can’t be,” adds Moy. And if that is to continue, we had to do better.

According to Dash, prioritizing this level of transparency connected to an internal ethos we have at Fog Creek about empowering our employees too.

“We talk a lot about how everybody at the company should spend the company’s money as if it were their own. To do that right, we have to give everybody enough information to know what our people cost. Finally, it put it in solid ground as we emphasized improving on inclusion in our hiring and promotions, so we could confidently tell candidates of all backgrounds that they were treated fairly.”

Fog Creek’s current culture around transparency didn’t come without some challenges.

“The tricky thing about having a 17-year-old company embrace salary transparency again is that a lot of the people that started at Fog Creek during this time didn’t intend to share their salaries when they accepted the job,” Moy mentions.

“We ended up using some industry databases to compare salaries and make sure we were being fair, but that didn’t quite give the team internal visibility or predictability into compensation,” adds Dash. “We did an internal audit and found we were competitive to companies our size and fair in terms of pay by gender or other factors, but people couldn’t tell that was the case. It was the worst of both worlds — the company was doing the right thing, but employees didn’t know, and employees wanted visibility but because it wasn’t there it seemed like the company was reluctant even though it wasn’t.”

As you can see, adding transparency to an existing company is not an easy feat. Dash mentions that our sibling company Stack Overflow was a great model of openness with their salary calculator and by sharing salary data gathered from their annual developer survey. Startups like Buffer have been at the forefront of radical transparency since their early days. Later in the week, we’ll speak with Courtney Seiter, Buffer’s Director of People, and gain more insight on how they have handled transparency throughout the years.

“Ultimately, not many companies are doing this yet. That’s why we think it’s a competitive advantage for attracting and retaining great people.”

Moy agrees, “it’s really important that we practice what we preach.”

Talking Transparency at Fog Creek

Recently, we introduced the ability to add a license or Code of Conduct to your Glitch project with just a click. It’s a great way to show the world that you want others to use your work as inspiration for creating even more amazing stuff.

But open source is as much about process and community as it is about any words in a license. And a Code of Conduct on a software project is meaningless if it isn’t backed up with real, substantive enforcement from someone who’s fluent in the relevant issues.

Whether it’s understanding the differences between various types of open source licenses, or choosing the wording of your Code of Conduct, we’ll be offering guidelines and interviews that will get you up to speed in no time.

We’re also thrilled to announce that we’ve teamed up with CodeNewbies for #CNC2018, the coding challenge that encourages you to meet your coding goal in 2018, whether it’s to start coding, code more often, blog more, or get a job as a coder. We’ll be teaming up with CodeNewbies to provide resources and inspiration to help you fulfill your goals.

Whether you call it a resolution, self-improvement, or just “practice makes perfect”, 2018 is all about learning on Glitch, and we’re here to help you every step of the way.

This Week on Glitch: Setting Some Rules

The excitement around and use of bots on the web continues to grow. Some studies suggest that more than half of all web traffic now comes from bots and automated sources. And like we covered earlier this week, there are many bots that do good in the world: from helping fight homelessness, to supporting people with mental health issues and alerting us to health problems.

Even the more prosaic, functional bots help us out by allowing us to offload repetitive tasks, like crawling websites for search, helping folks find good deals online, highlighting plagiarism and answering our customer service queries. Bots can help make the internet a better place.

But of course, that’s not all bots are used for.

There are those that create fake reviews, comments and posts on websites. As well as those that scrape peoples’ details to be resold. There are bots that create false ad impressions inflating ad costs, and those used for DDoS attacks that take down websites. Some are active on social media. It’s estimated that 400k bots were posting political messages during the 2016 US election, including 1,600 bots tweeting extremist content.

Some are used to harass, cyberstalk or impersonate people online. Which in response, has given rise to the creation of “honeybots” that post about specific topics to entice trolls and waste their time.

There was Tay, of course. Microsoft’s chatbot, which was designed to engage and entertain people in playful conversation. That went rogue, and began swearing, making racist remarks and inflammatory political statements. The flaw in Microsoft’s thinking? People. The system was designed to learn from its users, so it soon became a reflection of the comments it saw people making.

An automated copyright takedown request bot began targeting its owner’s original content, leading to his posts being removed from Wordpress while they sorted things out.

And others are well, just a little bit sinister. Like InspiroBot, which looks like it’s meant to create inspirational posters that combine relaxing imagery with an uplifting quote. But the resulting quotes are often far from that. Some are random, others meaningless, and many outright creepy.

For those who set out to do harm, or are focused on profit beyond concern for the negative impacts of their bots actions, that’s more a matter for relevant authorities, and the platforms they run on to curtail and stop them (Microsoft even has a Digital Crimes Unit!). But that doesn’t let creators off the hook. There’s lots that we can do to ensure our good bots don’t turn to the dark side.

From their beginnings, we can think-through potentially troubling actions and emergent behaviors. Such as by limiting the words or data that bots can use through use of blacklists of offensive words. Indeed, bot creators have already set about creating shared lists of potentially unsettling words that you can use in your own bot projects.

Consideration of the ethics and etiquette of bots is useful too. And folks have have written up suggestions of good bot etiquette, as well as guidelines on ethical bot making and Asimov-inspired bot rulebooks.

What’s more, the makers of the libraries being used to develop bots need to step up too, writing best practices into their developer codes of conduct. Like emphasizing the importance of disclosing that users are interacting with a bot through use of a welcome message, so people know they’re interacting with a piece of software.

Ultimately the responsibility for what a bot does lies with its creator. We need to put as much thought in to thinking through the inputs, outputs and vectors for abuse as we do it’s personality and functionality. And ensure that after we’ve pushed our creation out into the world, we monitor it’s behavior.

As bots continue to take over the web, it’s up to us creators to act like doting parents and guide our creations, making sure they stick to the straight and narrow.

When Good Bots Go Bad

20–30% of a team’s productivity is lost through inefficiencies in their workflow and communication (according to an IDC study) and email is a big part of that. But, we’ve all seen how communications tools like Slack help you tackle that, by reducing the amount of email sent within a team.

For many, Slack quickly becomes the team’s hub, where discussions about work happen and important notifications from the tools you use flow. But what about all those emails you get from outside your team, like customer questions and bug reports? Manuscript brings that Slack-like email reduction magic to project management. But that’s just one of the reasons why we think Manuscript is the best project management tool for teams that use Slack. Wait until you hear the other reasons, you’ll love it:

Manuscript lets you capture bug reports from users through email or a web form, it can handle core help desk tasks, and it can even take care of errors or bug reports sent directly from your products so that you can easily keep track of them and assign team members to handle them.

Also, like Slack’s message history, cases in Manuscript are persistent over time. So when somebody new joins your team, or somebody leaves your team, all of the knowledge they’ve shared and the decisions they’ve made are still captured in cases for future reference, instead of being lost in email. When combined with the powerful search capability in Manuscript, this means your team gets smarter over time and you’re not stuck scrolling back through chat logs trying to figure out who did what and why.

Plus, flexible notifications about updates to your project’s cases help reduce email too. And if you wanted to, you could completely turn off email notifications and trust the system to notify you of all the most important tasks and updates.

But good communication and project success takes more than a reduction in the number of emails. You also need the best tools and the right information.

We firmly believe that people should use the right tool for the job. So, while Manuscript provides project management, issue tracking, and support functionality, whenever you want to use another tool in your workflow, we enable you to use it seamlessly with Manuscript. That’s why we provide robust integrations with Slack, as well as other best of breed tools like Trello, GitHub and Google Docs, which are free to use, and fully customizable.

The Manuscript-Slack integration enables you to keep everyone in sync. Whenever you link to or mention a case in Slack, a helpful summary of it is shown. This includes the case number, project, area, title, status, assignee, priority, and most recent edit, so you and the people you’re chatting with have all the context they need to understand the case and its status, while continuing to focus on the conversation you’re having.

You can also use Slash commands to add new cases and update existing ones from within Slack. That means no more switching between tools just to make a quick edit!

But integrations with Slack are common in project management, so what makes ours different? Well, it’s fully customizable. You can view the code and remix the Slack integration on Glitch, and edit it however you need to. Glitch provides a browser-based code editor to modify the integration, and instantly hosts and deploys it as you make changes. This makes for a fast and efficient way to get an integration that works exactly the way you need it to.

Great communication is also about context. That’s why Manuscript organizes everything into cases. Cases are powerful — they capture any bit of information you need to stay on top of things, not just tasks in a to-do list. And they’re easily searchable, so if you remember that your teammate Kate resolved a case in the last month about a display bug, but you don’t remember the details, you can just search by what you do recall and it’ll pop right up.

And that context extends to documents too, so Manuscript incorporates document collaboration tools that make sharing technical specs, plans, design docs, knowledge base articles, and more, effortless. So no team member ever feels out of the loop.

And here’s the most important thing: Each case in Manuscript is assigned to one person. It’s a simple but powerful decision that means every responsibility in your project has a clear owner. This built-in accountability means there are no “who’s on first?” problems trying to figure out who owns a particular issue. Manuscript is opinionated so that you don’t have to have a team meeting, or even a Slack conversation, about whether somebody filled out a ticket correctly.

Using Manuscript and Slack together gives you just enough process to follow your own workflow, so your team doesn’t have to jump through hoops. All while keeping work flowing, so everyone knows what needs to be done and when.

Learn more about how your team can be more productive with Manuscript. Start a trial, and add the Slack integration from the integrations page in Manuscript (go to the Avatar menu > Integrations, and click the Slack tile).

The Best Project Management Tool for Slack Teams

We kicked off this week talking about bots — convenient programs that can automate any number of common functions. Let’s take a closer look at some of these fascinating bots, including a few from the Glitch community!

Bots can help you with a lot of different tasks to get you through your day. Take Woebot for example, a friendly bot that uses Facebook Messenger to check in with you about your mood, teach you new things and give you insight on your behaviors.

There’s also Resistbot and WeBot: two helpful bots for civic-minded citizens. Connect with Resistbot to find out your local senator or Congressional representative, and deliver a message to them in just two minutes. WeBot takes activism a step further by allowing you to discover and receive alerts for nearby protests. Both of these bots are a great way to take activism and advocacy efforts offline and into the real world.

Need more inspiration? Here are some examples of fun and useful bots from the Glitch community!

Glitch user Elisa made a wonderful and practical anxiety check-in bot for one of her classes using Botkit, a popular open-source developer tool for building chat bots, apps, and other custom integrations for messaging platforms.

Curlsbot is for anyone who needs help with caring for their naturally curly or wavy hair. This bot asks a series of questions to determine your hair porosity, analyzes the ingredients lists of products, and provides recommendations to help you get the best results for your hair.

Two great Twitter bots — @TroveListBot and @TrovePoetryBot — use publicly available data from Trove to help you find and use resources relating to Australia. So whether you need a little poetry or just want to get your fix of koala content, these bots are here. 🐨

There’s also Glitch Notifier — a Slack bot which notifies you immediately whenever someone asks a question on Glitch. This bot is a great way to share your knowledge, pay it forward, and help out the Glitch community of creators!

Have these examples motivated you to create your own bot? You’re in luck, because Glitch has a number of resources to help you build bots for anything you can imagine.

Let’s begin with our directory of handy bots; a great starting point for creating your own bot. There are example projects here that tie into Skype, Discord, Mastodon and lots of other messaging services. Remix any of these bots and make them your own!

How about making your own Slack bot? We have several example projects available that can help you make an onboarding bot or build something more powerful using Botkit.

Looking for more inspiration? Check out Botwiki: an open catalog of dozens of friendly, useful, and artistic online bots that connect to a number of different messaging services like Amazon Alexa, Google Assistant, and more! Get started by remixing any of these Botwiki projects on Glitch and show us what you create!

Hopefully these bots spark your creativity and make you think about what you can make today using Glitch!

Bots for Good

Anil Dash is CEO of Glitch, and the host of Function, a podcast exploring how technology shapes culture and society. 

He also serves on the boards of Stack Overflow and the Data & Society Research Institute, and was formerly a contributing editor of WIRED. He’s been blogging since 1999 and won’t stop telling people about that one time he was on the Desus and Mero late-night show.

Maurice Cherry is Glitch's creative strategist.

Incidents

The Workers Who Keep the Web Safe in an Unsafe World

Animal Crossing Helped Me Get Back to Real Life

New Rules of the Classroom: Remote Teaching in the Age of Covid-19

Better Tech: Why We Need Calm Technology Now More Than Ever

Function with Anil Dash

Open World is a fiction anthology podcast about how science and technology serve as a backdrop for imagining a better future, helping us envision the positive influence that science and tech can play in a real future. 

Open World is produced by Keisha "TK" Dutes and hosted by critically-acclaimed podcaster Rose Eveleth, for Glitch. By speaking to the pressing concerns of our times through love, friendship, community, compassion, and sustainability, the host will help listeners imagine new ways forward into a future that is less scary and more positive, and something we can start working on constructively.  

Open World launches weekly episodes in Spring 2020. Want to contact the show? Email youropenworld@glitch.com.

Open World

Shift Shift Forward is a podcast that showcases everything that makes Glitch the best place to create on the web. We’ll talk to some of our top creators, explore cool apps, and even hear from the people who work at Glitch!

Shift Shift Forward

Celebrating the makers, creators and coders who shine.

Recent Posts