GitLab Making Software Development Great Again
GitLab Making Software Development Great Again
GitLab is addressing concerns about violation of intellectual property agreements in a way that will encourage developers to participate in side projects again.
Join the DZone community and get the full member experience.Join For Free
Sharing his pioneering insight on how organizations can transform their software development and delivery processes, Gary Gruver provides a tactical framework to implement DevOps principles in Starting and Scaling DevOps in the Enterprise. Get your free copy.
As software developers, one aspect that most of us have in common is the desire to work on projects outside of our daily job. These side projects can range from contributions to open-source projects, volunteering time for a non-profit, participation in a hack-a-thon, or performing development tasks for an additional income source.
The drive and desire for developers to participate or lead side projects could be viewed in the way that an artist continues to refine their skills. In an industry which thrives on continual change, such projects can help individuals maintain their skills - expanding their knowledge along the way.
However, these side projects could have legal implications, based upon your employment agreement.
The Impact of Intellectual Property (IP)
Based upon a recent Twitter Poll, 85% of those participating indicated they maintain a technical side project outside their primary place of employment. Of that 85 %, the poll indicated that 46% utilize the hardware and software provided by their employer to complete this work.
For that 46 % and even the 54% using their own hardware and software, the potential risks associated with intellectual property (IP) agreements can be a cause of concern - based upon the nature of any signed agreements or corporate policies that employees must review and acknowledge as part of their employment obligations.
It might make sense to view the scenario from your employer's perspective. Employees at American-based corporations often work eight hours a day, five days a week - yielding a 40-hour work week. The employee is expected to work each week - except when personal or corporate holidays are honored. For the employee's time, payment will be made either at an hourly rate or some type of salary.
For the application developer, those hours are spent building or maintaining applications which help the corporation manage or track their business. As the developer continues to generate results, they are learning along the way and becoming stronger at their craft.
Where things get blurry is when the employee uses that knowledge for tasks outside their primary job. To some employers, they feel that their skills and abilities are the result of their employment and similar work (however that can be defined) is the IP of the company and the employee.
Some employers may even go as far as looking at only the skills of the individual and are not concerned if the use of company resources (like a company-provided computer) have been employed in the side work being completed.
To the employer, they want to protect their investment in software applications, not allowing developers to use a side project to create a better solution and offer it to a competitor.
GitLab Making Another Change
While the number of corporations actively pursuing the side projects of their application developers may be rare, the situation does exist - which can be a concern based upon the verbiage within either an employee agreement or corporate policy document.
These such concerns are the reason why GitLab recently announced what they refer to as a "more balanced Proprietary Information and Assignment Agreement (PIAA)." Following GitLab's switch from a Contributor License Agreement (CLA) to a Developer's Certificate of Origin (DCO), the executive team took things a step further by supporting developers who enjoy participating in side projects that are unrelated to GitLab's business, including other open source projects.
Building upon the March 17, 2017 Balanced Employee Intellectual Property Agreement (BEIPA) created by GitHub, the team at GitLab decided they needed to make a change to their PIAA - providing encouragement to developers who wish to work outside their GitLab projects.
In the December 18, 2017 press release, GitLab announced, "At GitLab, we want to give our contributors confidence that their developments will not be owned by GitLab simply by virtue of their use of GitLab-issued computers, GitLab facilities, or the GitLab source code repository. Furthermore, we want to alleviate the stress of not knowing whether they are in violation, given that there is necessarily some ambiguity about which projects relate to or don't relate to our business. So, we are making some changes."
What Are the Changes?
The changes being made by GitLab can be broken-down into three core principles:
Elimination in the section of their PIAA which states that any work completed on GitLab owned devices or repositories are the IP of GitLab.
When a "gray area" appears causing concerns over PIAA/IP, a process has been put into place where GitLab can reach a conclusion regarding the nature of the work being performed.
Revised their employee handbook to provide guidelines on when developers should seek further assurances from GitLab related to PIAA/IP.
Of those polled in the Twitter post (above), 44% of the respondents maintained some degree of concern over IP issues related to contributions of a side project. The changes put into place at GitLab are intended to ease these worries, with the hope of leading other corporations to follow suit.
Have a really great day!
Opinions expressed by DZone contributors are their own.