46
Show the site is safe and will not infect our computers
It's not "safe". GitHub allows anonymous users to upload anything they want including malware. You could get infected by downloading/executing code or visiting anything on the "github.io" domain where arbitrary javascript (and therefore 0-day browser exploits) might be found (github.com is safer ...
33
what is the best way to go about being an active, influential FOSS contributor?
The two goals I bolded that you seem to be asking about are quite different.
Many open source projects start because a person has a problem, and they want to share their solution with other people (the original developer is altruistic) as well as collaborate with others on ...
24
Make it clear that you want contributions.
Make it easy.
I would start by putting a friendly note in your project's ReadMe file.
This project is looking for contributors. If you have a feature you'd like to see implemented or a bug you'd liked fixed, the best and fastest way to make that happen is to implement it and submit it back upstream for ...
22
The idea of the Cathedral and the Bazaar is a metaphor from the book named surprisingly 'The Cathedral and the Bazaar' from open-source avangelist Eric S. Raymond.
The metaphor describes two different development-models for projects (not necessarily open source).
The cathedral is a centralized effort. A defined group of developers (or even only a single ...
22
There is a giant problem with the logic behind this fuss. Storing the source code of malware is not strongly correlated with being infected with malware.
Consider http://www.metasploit.com/. It's a tool used by people protecting against intrusion -- and also by people looking to perform intrusion. Or any number of other resources used by people who study ...
21
Note that when you say it's "unnecessary", you mean unnecessary for you. That's not the right way to collaborate: if you want others to contribute then they should have the same conveniences as you (build files in the repo for their preferred build tools).
I think you can politely reject the patch, with a remark that you would accept a patch that contained ...
21
I would say that projects having a BDFL ultimately trust the vision of the project to one person, as opposed to design by committee.
You can refer to the list of BDFLs.
Many of the individuals listed there have strong opinions as to what their respective project should do, not do, and how it should function (DHH and Theo are examples I am familiar with). ...
19
Most FLOSS projects are a kind of meritocracy: those who contribute(d) a lot, they have a say. The well-known projects are not new projects and especially the maintainers often work on them for many years.
Thus if you want to influence projects, you have to earn your standing with the existing contributors. You can only do that by friendly, on-topic ...
18
Don't merge, unless it meets your demands. All contributions are welcome, but only those that meet your standards are merged.
Whether that is test coverage, a style guide, or documentation, it shouldn't be merged until it's OK. You can choose to do it yourself when you're merging, or you can turn down the patch until it does.
As the maintainer, you are ...
18
I've always seen the BDFL model as halfway between a traditional open-source project structure and a traditional corporate project structure. You have the openness, transparency, and general culture of OSS, but with a single strong project manager to make high-level decisions and direct the overall effort.
You can see many of the advantages just by breaking ...
16
Reject it with a message.
Don't accept it; accepting it sends the signal that this is a good contribution and you want more of them. If that's not what you want, don't accept it.
What you should do is reject it with a note explaining why, for example:
Thanks for your contribution. Your patch was rejected because it simply replaced config files. Since I ...
15
To me, this question is very similar to how do I attract customers to my business? except instead of cash, you want contributions. Successful salespeople deeply understand their customers' needs and tailor their services to address those needs. It's a very powerful method: put yourself in your potential contributors' shoes, and ask what's stopping you. Many ...
14
Be more of a team player. Comments like
There's always an "in" group that's running things about how the project works and aren't accepting of new ideas and innovations even if they are backed up with facts and statistics.
would really scare me off having you as a contributor on a project I ran - even if you don't say things like that directly, it's what ...
13
Some guidelines that may be of use:
Always thank the submitter for their patch (unless you really don't want them to submit any patches anymore, which could be possible)
Establish guidelines for patches, and make sure contributors can easily find them. If you don't want IDE config changes, put it in your contributing.md (or equivalent).
Let submitters know ...
12
Open-source maintenance is often volunteer work. As a volunteer, you do not owe your time to anyone and can always say “no”. So it is absolutely legitimate to close any issue that is not comprehensible, ideally with a polite message in simple English that has a good chance of surviving machine translation. I would consider such a response to be more polite ...
11
This is part of the purpose of version control systems, like git.
When someone makes a new feature, or changes any code at all in fact, they have to commit it to the project. It's a bit like editing here on Stack Exchange: when you edit your post, an item is created in the post's history showing the changes.
If someone sabotages your post (or in this case, ...
11
I would believe that testing the project is the responsibility of all collaborators. It should fall under the hands of the contributor, as well as the maintainer. For example, a contributor should never let this go through (code in Python):
import os
os.system("rm -rf /") # Mua ha ha
Contributors should be wary of what they submit, but they make mistakes. ...
11
Congratulations! The problem you face is a common one for a popular open source project.
IMHO, beginners should above all learn to communicate!
So you could explain in your CONTRIBUTING file what a simple process would be when someone wants to work on a ticket.
When there are multiple aspiring contributors I make sure that each is aware that others may ...
10
In corporate software development, all developers are, typically, using the same IDE running on the same version of the same operating system
This is a misconception. Example:
I run Eclipse Luna with openjdk-1.7 on Ubuntu 15.04, my colleague runs Eclipse Kepler with oracle jdk 1.7 (previously 1.6) on Windows.
Still we got our builds working.
The goal is to ...
10
I'm a solo programmer, not any firm. But suppose if I were to form a small firm tomorrow and decided to write a security guideline regarding what to allow/disallow from github, it will be implemented something like this:
Only allow github.com domain and not github.io. Reason is that the latter is a web-hosting playground where any random developer can place ...
9
This is a really broad subject so I'll answer at a very high level and not touch specifics unless they are relevant for OSS.
"Works for me"
This is really the crux of the problem; you have build environments that are different in a way that affects software behaviour. The industry at large has been tackling this for decades, and a number of best practices ...
9
I'm playing with the wording in your question a little bit, but don't change it up because it will likely make this entire answer invalid.
Anyways, let's break down the question by well... question:
What happens if the main contributors of an open source project die?
Well, the project will die down. Likely, a lot. The key part here is that the core part ...
9
Start by writing down a list of current issues and make sure it's easily accessible. Other contributors will then have a clear objective: they can fix issues!
Continue by writing down a list of anything you would like to change long-term, in small steps. This allows new people to see what the initial thought behind the project was, and they might want to ...
9
Sadly, there is little you can do. I believe you can argue that you accepted the code in good faith, and avoid the worst. Try to collect and organize any evidence of the affair (emails, commit identifiers, ...). Keep a copy of the current version control system contents around.
To replace the tainted code, you can see if you can set different objectives (...
8
Discuss, discuss, discuss
This is absolutely essential. You can't solve personal problems digitally - so when I say discuss, I mean call a meeting. You need to sort out some things with him:
Project focus
If everyone has a different idea of where the project's going, it's obviously not going to work. This is the root of the problem. Discuss with him what ...
8
I'm a maintainer in various projects in GitHub with ~50 million weekly downloads but I am one person and can only share what worked for me.
Persistence.
The number one mistake I see people get is not set aside enough time to make a meaningful contribution, assume they're going to be awesome and then assume they failed when they don't get it right the first ...
7
I can think of a few points
Documentation is key - Not just usage documentation, but also development documentation! How do I build your project? How do I run tests? How do the internal APIs work? Github has the wiki feature for that, although you can just create a directory with a bunch of .md files.
Make your directory structure predictable - Look at how ...
7
You can recover that specific link via the way back machine:
http://web.archive.org/web/20150507060802/http://jira.codehaus.org/browse/MASPECTJ-131
codehaus says from their termination page that you can redirect your projects:
If you would like your projects links redirected then please see our redirector repository - create a sane squashed pull ...
7
First and foremost, testing the contribution is responsibility of the contributor himself, before submitting a patch, to see if it breaks something or otherwise causes problems when combined with the rest of the codebase. This is true for every programing job, not just open source, testing their own changes is the developer's responsibility.
That said, once ...
7
Just do it!
Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.
If the project is using Git, make sure you adhere to best practices with regards to branching and ...
Only top voted, non community-wiki answers of a minimum length are eligible
