6

Suppose you are working on a large open source project with 20+ people. Suppose one of these people get mad and decide they want to sabotage the entire project.

My question:

What measures (if any) could be taken to prevent loss of code and information, in the event of an internal sabotage?

  • 2
    What definitions of loss do you refer to? – Michael Schumacher Jun 29 '15 at 21:01
  • I'm tempted to vote for closing this as too broad - see my comment to ArtOfCode's answer. Maybe the question can be reworded to focus on a specific way of sabotage or of sabotage prevention? – Michael Schumacher Jun 29 '15 at 21:30
  • 1
    How would this be any different than in closed source projects? I'm not seeing the open-source-specific aspect of this question. – congusbongus Jun 29 '15 at 23:32
  • 2
    In a closed source project access to perform certain actions can be restricted to a small group of trusted people. It may not be obvious to all readers that this is possible for a non-closed project. – trichoplax Jun 30 '15 at 0:00
  • Suppose this, suppose that, something very vague happens, what could we do about it? Yeah, this is "too broad" almost by definition. – Air Jul 1 '15 at 23:03
10

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, project), then you can simply rollback the changes, setting your project back to the state it was in before the change.

The other method is of course backups. If for some reason this disgruntled individual deletes the entire project, backups are your recourse. Taking regular backups means you have a record, kept separately from the project, of the stages of development. You can then simply restore a damaged or deleted project from these backups.

  • 5
    While version control systems certainly make it easy to revert sabotage, they do not prevent it - and subtle changes, especially if they come from reliable members of the development team (or appear to be), might be easily missed - Heartbleed, anyone? – Michael Schumacher Jun 29 '15 at 20:32
  • 1
    @MichaelSchumacher Indeed they don't prevent sabotage, but they do prevent loss. – ArtOfCode Jun 29 '15 at 20:35
  • Good point - as long as you refer to loss of source code. Loss of other things - money, reputation, trust - can still happen if the sabotage is not discovered in time. And thinking of it, the question in its current form might be too broad, there are so many ways an internal saboteur can take to harm the project. – Michael Schumacher Jun 29 '15 at 21:07
3

Review and testing. That's all we got. If you want to be very careful, Review then Commit (RTC), so that someone affirmatively takes responsibility for each change as it becomes part of the main line.

Your question uses a very broad term, sabotage. Sneaking exploits into code is only one way that someone can try to be damaging to a project. Badmouthing, for example, is a whole other area. Building a strong community is the only defense, and meaningful code review comes from either a community or a BDfL.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.