SPO600 Lab1

Sept 9, 2018

In this blog I will be looking at two open source software and their community. I will discuss the license type, contribution channel, how to successfully submit contribution, and an example of successful contribution.
This is not meant to be a comparison between the two, but to get an general idea of how open source community works, and as a developer how to contribute to the open source software successfully.

Brave Browser

License:

  Browser-MPL2.0

  Privacy Badger-GPLv3

  HTTPS Everywhere-GPLv2

Contribution channel: GitHub

How to submit contribution:

To successfully submit a patch the contributor must meet the standard laid out by the Brave team. 

When the contributor have the documentation and working code ready, submit pull request to submit the patch.

For details visit Brave's Contribution documentation.

Review process:

Once contributor submits code via pull request, the code is then reviewed by the member(s) of the Brave team. Every contributions are reviewed by at least one member. The submitted code is tested following the steps documented by the contributor and using their use cases.

If the member(s) find any issues with the submitted patch, the solution is discusses between the member(s) and the contributor.

Once the found issues are fixed, code have been reviewed, tested, and passed use cases the member(s) approves the code and merges it.

Any issues found after the merge are commented and referred to as a new issue.

Example case:

A contribution I looked at was to fix random sampling with brave-crypto random samplers.

The contributor pull requested the patch and the patch was reviewed by two members.

Once both members approved the code, the patch made by contributor was merged by a member.

This contribution took 1day to get approved, but others have taken longer to get approved.

OpenALPR

License:

  Proprietary

  AGPL

Contribution channel: GitHub

How to submit contribution:

All contributors are asked to review OpenALPR design description before submitting anything.

Patches are submitted via pull request.

!Review process:

Contributor submits the patch via pull request.

The submitted code is then reviewed by a *member. If the member finds any necessary adjustment before accepting the submitted patch, he will leave a comment as to adjustment needed and reason(s).

Contributor, if able to, makes the necessary adjustments and commits the patch.

A *member reviews the code again and, if satisfied, approves the code and merges it.

Example case:

A contribution I looked at was to add multi-thread frame processing to daemon.

There wasn't any description/documentation of the patch provided by the contributor.

The code was reviewed by the *member and was requested to change to support C++98 for other users using hardware with older compiler.

The patch was re-committed by the contributor with changes.

The *member reviewed the code, approved and merged the code.

This contribution took 12days to get approved, but other contributions have taken lesser time to get approved.

Also, this contributor had CLA signed. I have seen others who have signed it and who have not.

Summary

Brave Browser have a very well structured procedure for accepting patches from the contributors. As mentioned above, they have full documentation that lays out what contributors needs to do before submitting their patch. Also, the code will never be approved unless it has proper documentation and have been reviewed and approved by at least one member.

The advantage of this is that the new patches are tested numerous times and is proven to work before it is implemented.

On the other hand, OpenALPR is more lax compared to Brave Browser. It does not appear to have official guideline for contributors to submit their patch. Many contributors had very little to no description of the patch, steps to test, and what and where the changes were made. Despite the lack of documentation, the patches were approved fairly quick without much adjustment request from the *member.

I guess the advantage of this is that there is only one person reviewing the code, so the format and structure of the code is consistent.

The disadvantage of this is that it takes some time for the code to be reviewed and approved due to lack of reviewer presence.

==Legends==

! - No official documentation found for pull request

* - Unknown status. The only person who reviewed, approved and merged the patches was labeled as 'contributor'. Based on the activities of this person I assume that he is an official member of OpenALPR.

==Note==

If anyone knows where to find the documentation on pull request for OpenALPR please leave a link in the comment.