1

We have decided to take down the publicly available wikiHow source code from src.wikihow.com . We feel that publishing our source code is not part of our core mission, and maintaining the public code repository doesn’t benefit the community or the company. While we are eternally thankful that Wikimedia Foundation is open, our goals diverge from theirs and we have found that making our code available for anyone to download creates distractions and problems for our relatively small engineering team. We will, however, continue to offer access to known community members on request.

Reason for this changeWe are finding that attacks against our site are happening that utilize knowledge of the source code. When an attacker does some research about our site beforehand, and realizes that we publish our source code publicly, they are able to target DOS attacks in a way that is more dangerous to our site’s health and availability.

We are regularly targeted for DOS attacks, which causes disruption to our service, disruption to our core mission and sometimes disruption to our sleep patterns.:slight_smile:Over the past few months, we have seen patterns of DOS attacks that clearly use our open source software as a stepping point to mount attacks against us. We have also seen an increase in attacks targeting Special pages only available to logged in users, mounted by bots masquerading as logged in users. We find these trends worrying because our site has many legacy software features, some of which are actively used by community members, that we do not wish to part with or rewrite. While we try to keep on top of security issues by doing periodic security audits and updates, we find that the size of our code base, number of features to be maintained, and age of our code, can already stretch our engineering team thin. We will not stop this practice of security auditing by no longer making our code open to the general public, but I mention it to explain that any significant advantage we can remove from attackers is valuable.

Lack of benefitOn the other hand, we have never benefited from an external researcher auditing our source code from a security perspective. We receive security-related Proof of Concept attacks against our site from external researchers, and we’re thankful for this. But these researchers have never shown evidence of using our source code to benefit their analysis. We also have historically not received patches to our code from open source developers. And other uses of our source code are typically copycat sites that attempt to exploit the wikiHow brand for their own gain. From a business perspective, the benefits of publishing our source code are strongly outweighed by the risks of keeping it open to anyone.

While this decision may disappoint some of the open source enthusiasts in our community, we believe it is the right choice for wikiHow at this time.

14 Likes
3

Understood. BTW anyone is free to get a distribution of the software wikiHow uses here , although you do not get any extensions that wikiHow has made.

4 Likes
4

Also @Reuben or @JayneG can you update https://www.wikihow.com/wikiHow:Powered-and-Inspired-by-MediaWiki with an email to request the code?

6 Likes
5

Updated! Thanks @Awesome_Aasim

4 Likes
6

Also, you need to update the src.wikihow.com page as it still links to a download. You can put a message that says “wikiHow’s source code is no longer available for public download. To request the source code so you can fork it, please contact support@wikihow.com . Alternatively, you can download the software wikiHow uses, MediaWiki, at mediawiki.org .”

2 Likes
7

@Awesome_Aasim Yes, we’ll update that site (or remove it) in a couple weeks.

3 Likes
8

I am retiring src.wikihow.com now.

6 Likes
9

Hi Reuben,

Thank you for keeping us in the loop. All I understand with this shift is that it is necessary to keep wikiHow safe. I hope you and others don’t experience more change in your sleep patterns.:slight_smile:

2 Likes
10

Great. Though it would be better if that src.wikihow.com link redirected to wikihow.com/wikiHow:Powered-and-Inspired-by-MediaWiki .

1 Like
11

Hi, disappointed open source enthusiast here.

While I can’t say that this is very surprising after late October 2014, when the skins/ directory was entirely removed from the public downloads, it sure is disappointing and I feel like it’s a move to the entirely wrong direction; of course, with the recent focus on wikiHow’s part on paid features and such, it’s not exactly shocking.

Measuring benefits is no easy task, but my wikiHow-related code contributions to MediaWiki core ( gerrit.wikimedia.org/r/q/owner:ashley%2540uncyclomedia.co+topic:wikiHow+status:merged ) alone should prove that at least the statement “doesn’t benefit the community or the company” is untrue. It’s very sad to see access to the wikiHow source code restricted even further, when I feel that the correct move would have been to push for more openness - a true source code repository where most stuff is open, not closed, by default. So that enthusiasts would have been able to communicate directly with engineering staff regarding code and submit improvements, directly file bug reports/feature requests/etc. But more about that later on.

DoS mitigation is, of course, essential for a site as big as wikiHow, and I certainly can see why you’d prefer to have a good night’s sleep as opposed to playing whack-a-bot online! That said, if there are issues with either MediaWiki core or extensions maintained upstream, please do submit a task on Wikimedia Phabricator ( phabricator.wikimedia.org/ ) so that such issues can be tracked, identified and fixed. Though judging by the last couple week’s changes, I guess you’ve been having more issues with custom extensions like SortQuestions and such?

Now, back to the whole “Lack of benefit” aspect. @Reuben , you say that “We also have historically not received patches to our code from open source developers”. Did you consider that this mayhave had something to do with the notice “We are not accepting patches to the source code” that was present on src.wikihow.com until the very end, as witnessed by this Internet Archive snapshot of the page from 17 November 2020: web.archive.org/web/20201117103829/https://src.wikihow.com/ ? Not that that would’ve stopped me from trying anyway: forums.wikihow.com/t/clicking-the-x-button-on-the-read-annother-article-popup-does-not-work-right/10816/3

Finally, I do want to mention my fork of wikiHow’s code, which I started in December 2017, called ShoutHow, available at git.legoktm.com/ashley/ShoutHow . While honing my own skills as a programmer and admiring the work wikiHow has done with MediaWiki, I’ve been working on things that I believe should be done in the main wikiHow codebase but that aren’t exactly a high priority for wikiHow, such as various i18n fixes, path fixes for more conventional URL setups (wikiHow’s URLs skip over the script path, which is not recommended by upstream developers, although of course it works for wikiHow), forwards-compatibility fixes to ease future MW core upgrades, and naturally outright bonkers stuff like SQLite or PostgreSQL support, support for different CAPTCHA types in PostComment and so on.

Here’s hoping that the legacy of open source wikiHow code lives on even after this regrettable decision that seems to be based on incorrect information…

(N.B. Apologies for preformatting the links. I kept getting an obnoxious "Sorry, you can't include links in your posts. error when trying to make the links clickable or letting the autolinker turn them into clickable links…)

5 Likes
12

I think the main issue is that wikihow’s code base is very different from Wikipedia. If we just ran vanilla mediawiki with all the same extensions, we would still function. Just not with some of the legacy deprecated features. And I believe the source code is still available to developers under the GPL license, it is just that for security reasons it is no longer publicly posted.

13

Keeping the src code as is or moving them, what is open to all is the ‘choice’. Everyone has a right to choose what they think is fit for their enterprise, without giving them grief for a move in another direction from the rest of the herd. Going against tide is something that does not go down well with those who like things in a certain way. However, wikiHow is free to choose what is best for it’s security, growth, popularity and also returns. I wonder why people point to it like they are talking about Corona virus. Kudos to wikiHow for turning, moving, retracting or whatever they felt and knew was correct. It is steps like these that make wikiHow so different from anything else in the world. I hope no one feels let down by where wikiHow goes. Wherever that is, it is not against someone. And it deserves to go as far and wide as possible it is as accepting, encouraging, and cheering as it is progressive.

1 Like
14

Sorry, VY, but I have to respectfully disagree here.

Historically, wikiHow has always done its part to foster a sense of openness and community control. I can’t speak to the open-source community specifically because I know nothing about the community or programming, but removing the source code and only making it available to known community members upon request - particularly when the community has been given the right to fork if it should ever be needed (though hopefully it’s not) - does not mesh well with that. Not to mention it’s fairly misleading to say that wikiHow has never received a patch from an outside developer when the source code website appears to have stated since its creation that they do not accept patches from external developers.

We’re a community-based project - it’s understandable to have negative feelings about losses of volunteer autonomy, even if they’re meant for the good of the site. I’ve felt some frustration at some of the expert review project, even though it’s necessary, because I’ve seen questionable things in the past and not gotten follow-up or had to message staff to fix or remove content that I’d normally be able to handle myself. I’ve seen people express frustration about no longer being able to move established articles because staff discovered that it results in a drop in readership, or that a contracted team overwrote their content when the existing content was already helpful, or the recent move to paid memberships when our Mission was always to provide free instruction to everyone. The reality is that while staff does need to do things that benefit the site, what benefits the site does not always benefit the community, and it’s entirely okay to be upset about that.

4 Likes
15

Why does it not mesh well? We need to work with the articles. Not the source code. What good can come out from having access to the code? I mean, we can ask for access if we have a valid reason. Doesn’t it serve to safeguard it from vandals?

You can have a clear dialogue with the haus about not acquiring patches. I don’t think asking about every minor detail serves well. But if it troubles you, then having it cleared is a good idea.

We are a community and a staffbased project, Alex. I think we must give them space for creativity and I’d say autonomy too based on their qualification, and experience. There’s nothing low about being realistic. I mean I know they have at least two who have a PhD. The rest are either bachelors or master’s or still pursuing further education. That kind of stamp ‘assures’ the staff if not to gain more favor but atleast to have the satisfaction. What about us? I mean, yes we are educated and or are students. But they don’t compel us to share our background with them to build trust. Its upto us. So, the staff should be considered with their decision making. There were dialogue gaps. But whenever one from the community speaks up, the staff lend a ear. It gains traction and also leads to a change like the articles now have - Approved by so and so expert and 10 Contributors. I have seen 202 contributors too which looks eye popping. But let’s not mull over it too much.

When wikiHow wants to move ahead, like you and me and we all do, people pose questions about the authenticity of our content. Just imagine the dilemma of staff who value the community yet can’t vouch openly for their content because readers want a stamp? They only do what they do, neutrally. Their motive may seem like going against us however, if you see from their point of view and what they are exposed to in terms of review, which might be brutal if we see them directly, we’ll know that they just want to add credibility to the article, keep also the community and keep going. Where does the question of devaluing the community comes here?! If in this entire process, we feel left out, we should say it. Like we do. Like you did with the expert author review. And it ended beautifully. When there’s a mismatch, we speak up. Hopefully, not blurt out because they are people too. They have said that they make mistakes too. How and what more should the staff say? We should let go of our pent up anguish once the issue is discussed and accept them without keeping past disappointments in mind to work together. That’s what learned and sophisticated minds would do.

Not being able to move articles because you need to speak to the staff is a lengthy process but for a reason. If we move at will, our will can be affected by feeling left out too. It could become subjective. Such base should not affect articles. If the articles are dear to us, how much more dearer will it be for those at the haus. Won’t it be? How much do you think it all means to them?

The content is under creative commons. When we edit their work, they can also edit our content. Even if our articles are helpful with good readership, does not mean it can’t be made better and more can’t be incorporated based on feedback, google search criteria and what people need. I’ve seen authors discussing and rolling back to the previous version. However, allowing the staff to experiment with ‘our’ content and finding what works better requires trust. We should trust them when we call us a wikiFamily. We treat them harshly, I think. They are still very sporty with our attitude but we must wait to see their intentions and attitude. They’re humans. They’ll learn. We have been learning from them or wikiHow as soon as we joined. Haven’t you changed a great deal? Who is to be thanked? Have you considered asking how the staff strive to make the assume good faith work? And if you care enough to rely on them especially when we are frustrated?

Paid memberships about those courses? Why should that bother anyone? Those are not articles on wikiHow. Articles have to be free as it is a wiki. Other ventures wikiHow gets into, isn’t it their call? We can be volunteers here and make money on YouTube channels. What’s wrong with making money! The mission of the how to manual must remain the same.

3 Likes
16

I’m a little confused on the strength of the response here. I’m not angry or upset, and I didn’t say any of these things were outright bad and that we shouldn’t have them. My point was more that just because something benefits wikiHow as a website does not mean it benefits the volunteers themselves, and it’s okay for them to be upset or disappointed about that.

And to be 100% honest, I know they’re human, but that does mean we need to acknowledge staff and contractors can be wrong with some changes, too. I’ve told off Seymour Edits before for gutting articles to add unhelpful or completely inaccurate information (and have even expressed frustration to family about how I’ve proven I’m a good writer and still can’t get any contracted/paid work with the site simply because I don’t have a degree), you yourself acknowledged that we had an outcry when it came to expert vs. community co-authors, and that’s to say nothing of the on-site experiments they try to see how readers respond and don’t go through with just because it turns out readers don’t like them. They’re good people and they have good intentions, but just like the volunteers, they aren’t infallible. If we can’t express disappointment or frustration to them when they do something we dislike, or when we lose a degree of autonomy to no fault of our own or staff’s, then we’re not a community, we’re volunteers for a corporation that won’t listen to us. They’re making the effort to not be the Big Corporation That Won’t Listen™, and they have to make some compromises, but we need to be able to express these thoughts so they have the opportunity to listen to us and make these compromises in the first place.

3 Likes
17

Alright, I’m sorry about not getting your tone here.

Then there’s only two things left to mention -

  1. We can acknowledge staff. I don’t see them in need of anything from us, individually. However, we can be embracing to them too. Because it’s the both of us that work together. None stands alone.

  2. I’m sorry about you not getting paid work because of the lack of a degree. But it’s a standard protocol companies have to follow. Even if they have a prodigy, they may not see fit to bend the rules for them. A degree is a must where they have it in their rule books. I hope you get work that justifies your talent and knack for accuracy. I also continued my studies when my computer class teacher told me that to get a good job, you need to atleast pass graduation. And so I did. I hope you do it too.

18

wikiHow, while its source code is entirely licensed under the GPL because MediaWiki, has made a decision as a company to take down copies of its source code. This is mainly because of the security risks and because of all the security vulnerabilities and maintenance that needs to be done to make wikiHow’s extensions work. They also have a radically different MediaWiki parser that makes it difficult to upgrade the software when needed. Not to mention that not every website discloses its source code. In fact, wikiHow’s source code is already published and made available at https://mediawiki.org/ . You just do not get the same extensions and skins as everything else. If you want to consider contributing to MediaWiki, you can definitely do so at https://gerrit.wikimedia.org/ and at https://phabricator.wikimedia.org/ .

2 Likes
19

@Jack_Phoenix

We also have historically not received patches to our code from open source developers.

Regarding this issue, I never meant to imply that this was anything other than our policy. (The policy has been in place for good reasons. We believe it would have been difficult to work with external patches, given the focus, structure and size of our engineering team.) I mentioned the lack of benefit in not receiving patches because, for some companies, this might have been a primary benefit of maintaining an open source project, but that was not the case for wikiHow.

2 Likes
20

I would also just like to point out that the mere fact that I’ve posted that I’m blue with purple polka dots publicly in a forum does not make me blue or purple polka dotted.

We have no way to verify or confirm the facts as stated by Jack Phoenix. They could be Jack Herrick… or just a JackA-- looking to make trouble.

Corollary pun… It may be that they don’t know “jack”…

3 Likes