Category Archives: Development

Development technologies and projects

Legal Cred for an Open-Source Project

I am not a lawyer. The information here is not, not is it intended to be, legal advice. 

Many open source projects unfortunately don’t concern themselves with presenting a clear legal perspective, which could be costing them community!

An open source project must present legal credibility to be considered seriously by a commercial enterprise.

I recently attended the iTech 2017 convention in Calgary, where the luncheon keynote was Digital Transformation Leaders Are Few and Far Between from Snehanshu Shah, SAP Global VP Customer Innovation. Shah purported that leading companies in digital transformation will use next-generation technology to continuously improve core infrastructure, while quickly incorporating new technologies for competitive edge, and that technologists who can apply inexpensive technology to solve these business problems will have value. Open-source software is now a proven development model with communities of essentially independent developers, collaborating in a non-competitive environment and sharing the development labor. It is inevitable that the business transformation spoke of by Shah will be aided by open-source software technologies, driving down the cost of infrastructure and providing sources of competitive advantage in a digital age.

It is in the nature of a young open-source project team to organise itself loosely. This should not be surprising, considering project members are typically volunteer developers donating their time to scratch their own personal itch, and more interested in writing code then in documentation or project process. A mantra of the open-source community is Talk is cheap. Show me the code. However, this is not to disparage project teams because it is hard to have value without working code.

Unfortunately though, this behavior is in contrast with a commercial enterprise’s typical need for security and stability to operate in the best interests of its owners. An enterprise must be absolutely confident that their adoption of a particular open-source software application cannot be jeopardized later, for example through misunderstanding or lack of appreciation for legal concepts by the project team, or a falling-out within the team leading to a disagreement over code ownership. A commercial enterprise requires confidence of longevity.

Ownership (Copyright)

The fundamental aspect of credibility is clear ownership of source code and other assets. Major projects often require contributors to sign a Copyright Assignment Agreement (CAA) or a Contributor License Agreement (CLA), which for all intensive purposes transfers ownership of the contribution to the project. However, this requires creation of a legal entity to assign or license contributor rights to, which is often beyond the need or ability of a smaller project team.

Simpler approaches are possible. For example, the Maestro project includes a legal statement in one of the project’s source code files – in the README.md file. The statement specifies the license under which the software can be used, that contributors retain individual copyright to their work as recorded in the repository commit log, and that contributions are accepted with the assumption they were provided under the terms of the same license. The legal statement was committed to the project repository before any contributor contributions were accepted. This approach was deemed sufficient considering the project potential and risks, and ultimately a business decision.

License

The second-most fundamental aspect of credibility is the license, and the license terms that control use of the software. To have value, the license must be be legally binding and enforceable. Well understood and even legally tested licenses exist, but many open-source developers still write their own license, based on how they would like their software to be used. For example, Anuko Time Tracker, a popular web-based timesheet system, uses its own Liberal Freeware License, which appears to address the same concerns as more established and tested licenses such as the BSD, MIT, and Apache licenses. To an enterprise, not using a well-known and understood license can easily prevent an application from being considered further. Enterprises must be concerned with potential liability, and a well known and tested license will provide greater credibility. 

Permissive vs Copyleft

The anticipated use of the software must of course be compatible with the terms of the license, but also potential future use should be considered. There are two basic types of open-source licenses, permissive and copyleft. The two have very different goals and different implications for a commercial enterprise.

The goal of a permissive license is to encourage use through as few restrictions as possible, while the goal of a copyleft license is to ensure source code remains available even if modified by a third party. Commercial enterprises generally prefer a permissive license to a copyleft  license because it reduces risk of the license constrain the business at some point in the future. 

The original copyleft license was the GNU GPL, which required that source code be provided to everyone the application was distributed to. When remotely served web applications became popular, it was realized that GPL-licensed web applications hosted remotely did not have to make source code available, because the application wasn’t being distributed according to the GPL. This was against the philosophy of the copyleft community and became known as The ASP Loophole. As a result, the GNU Affero General Public License (AGPL) has become the popular copyleft license for web applications, requiring that source code be available to anyone who accesses the application. However, having to make source available should not be the greatest concern to a commercial enterprise for a copyleft license. The greatest concern should be whether the copyleft license could constrain future business direction or opportunities because of how the license extends itself to integrated – or integrating – applications to also apply to the end result. 

To explore this using an example, first assume an engineering department within a commercial enterprise is trying to improve project management, and starts using Anuko Time Tracker as an electronic timesheet system to record time spent by employees on projects and tasks. If use of  Time Tracker proves successful, the enterprise may expand use to other departments as well. Eventually the enterprise may make minor customizations as well as provide access to contract staff for entering their time, and to clients for reviewing their project’s dashboard. Assuming Time Tracker continues to be successful, the enterprise may want to integrate it with other internal systems, such as a vacation database or ERP system.

Because Time Tracker  uses the permissive Liberal Freeware License, there will be no practical constraint on how the enterprise can use, modify and integrate Time Tracker –  ever. However, if Time Tracker had been licensed using the AGPL, not only would customizations have to be shared with clients, subcontractors, and possibly competitors, but integrations with other applications may be impossible due to incompatible licensing. While it may be possible to perform an integration without the copyleft license becoming “viral” (a popular metaphor, implying that a copyleft license “infects” everything it touches), careful review of both the specific licenses and of the software architectures involved will be necessary to establish business viability.

In Conclusion

If you want to attract enterprise users to your open-source software project, then remove obstacles from their path. It doesn’t matter what you think, it’s what they think. Perception may not be reality, but it’s perception that matters. Make it easy for outsiders to understand the legal position of your project, and what the implications and options are.  

There is a plethora of legal advice on the internet, some useful, some less useful, and some absolutely wrong. Laws are specific to a jurisdiction, and much will simply not even apply to you. There are also subtleties and implications that only an expert can competently advise on. If it’s important, seek professional guidance!

For more anecdotal information, TWIT.tv‘s FLOSS Weekly podcast interviewed several project teams that had to deal with legal issues.

  • Roberto Rosario had to develop Mayan EDMS in a way that would permit GPL licensing although he was working as an employee of the Porto Rico government, and also deal with an early fork that threatened the project’s future. See FLOSS Weekly Episode 253.

 

Remember, if it’s important, seek professional guidance!

Install ERPNext on FreeBSD

Frankly, the simplest way I have found to install ERPNext on FreeBSD is to use the ERPNext Virtual Image with VirtualBox and phpVirtualBoxVirtualBox is supported on FreeBSD, and phpVirtualBox is a popular web application that duplicates the native VirtualBox manager for headless servers (and saved me from learning the intricacies of the Virtual Box cli). A big shout-out to Ian More for creating phpVirtualBox, and to the phpVirtualBox community – including decke@FreeBSD.org for updating the FreeBSD phpvirtualbox port and package

Several years ago I attempted to install ERPNext on bare metal FreeBSD using the ERPNext Easy Install script, but eventually had to switch to CentOS. This time I decided to try VirtualBox. I initially considered the BSD hypervisor bhyve, but bhyve does not directly support an Open Virtualization Format (OVF) disk image (although it is reportedly possible to use qemu-img to convert the OVF image to a raw image, which is supported by VirtualBox).

The server is de-branded HP Media Centre PC, with an E6600 Core 2 CPU and 3 GB of DDR2 PC2-5300. I was concerned about performance with only 3 GB of RAM but usability has been satisfactory, albeit to date under relatively light load. htop shows an increase in RAM and swap use with VirtualBox, but RAM use is still below 1 GB and swap use is under 100 MB.  

Please comment if you found this information useful. It’s kind of a poll. Thanks.

Install VirtualBox

# pkg install virtualbox-ose

The vboxdrv kernel module needs to be loaded at boot, done by editing /boot/loader.conf

# vi /boot/loader.conf
...
vboxdrv_load="YES"

Reboot the system to have the kernel module loaded.

The user that VirtualBox runs as must be a member of the vboxusers group. For simplicity, I’ll run VirtualBox using my own username, although best practise would be to create a dedicated user.

# pw groupmod vboxusers -m dale

Edit /etc/rc.conf to run vboxwebsrv (the Virtual Box web interface daemon) using the provided startup script installed in /usr/local/etc/rc.d/

% sudo vi /etc/rc.conf

vboxwebsrv_enable="YES"
vboxwebsrv_user="dale"

and finally start the vboxwebsrv service.

% sudo service vboxwebsrv start
% sudo service vboxwebsrv status

This however does not actually start a virtual machine. I will be using phpVirtualBox to manage virtual machines interactively. However, a vboxheadless rc.d script is also provided to start a virtual machine automatically during boot. 

Install phpVirtualBox

Install phpVirtualBox.

# pkg install phpvirtualbox

Edit the phpVirtualBox config.php file appropriately.

# vi /usr/local/www/phpvirtualbox/config.php

var $username = 'dale';
var $password = 'dale_login_password';

Finally configure the webserver to serve phpVirtualBox. I use Apache 2.4 and added a virtual host definition to /usr/local/etc/apache24/extra/httpd-vhosts.conf to serve phpvirtualbox as a phpvirtualbox.dalescott.net.

<VirtualHost phpvirtualbox.dalescott.net>
  DocumentRoot "/usr/local/www/phpvirtualbox"
  <Directory "/usr/local/www/phpvirtualbox">
    allow from all
    Options None
    Require all granted
  </Directory>
</VirtualHost>

“Install” ERPNext

Download an ERPNext Virtual Machine image (*.ova file) to /usr/local/etc/vbox (a suitably arbitrary location).

 % wget http://build.erpnext.com/ERPNext-Production.ova

Using phpVirtualBox, create a new vm by importing the downloaded ERPNext-Production.ova Virtual Image file (File/Import). It includes port forwarding rules to forward client port 80 (used by the vm to serve ERPNext) to host port 8080. There is also a rule to forward ssh from client port 22 to host port 3022.

Start the vm and then login to ERPNext from a browser (e.g. www.dalescott.net:8080) using the default credentials. The new site wizard will run and lead you through ERPNext configuration. Use a secure password when defining the initial (admin) user, and the wizard will delete the initial Administrator user (with default password) when complete. 

Once logged into ERPNext, you will likely want to setup email processing so that users will receive notifications outside of ERPNext. This will be valuable to understanding and appreciating ERPNext’s significant social aspect. You will also want to change the password for the configured system user to something secure (or even disable password authentication entirely in favour of key-based authentication).

More about phpVirtualBox

phpVirtualBox may be a project in transition. Although researching the internet showed phpVirtualBox to be the most popular web UI for VirtualBox, it still appears to depend primarily on the project founder for development support.

The phpVirtualBox project was first hosted on Sourceforge. Although the code repository was later moved to GitHub, Sourceforge still hosts the distribution archives and documentation wiki.

The future of phpVirtualBox though is not completely certain, which is unfortunate as phpVirtualBox is the only web interface for VirtualBox. The GitHub repo is the only repo managed by the phpVirtualBox organization, which has has no public members and no written statement of direction. The FreeBSD phpvirtualbox port update from July 2017, billed as an “unofficial 5.1-1 release” was cherry picked from unaccepted community merge requests and included the comment “Sadly upstream is very silent”.

However, given the popularity of phpVirtualBox, and that it’s licensed using the GPL v3, I’m confident it will survive.

Web-Based Timesheets for Project Management

What is project management? What it isn’t is a carefully crafted Gantt chart made to support a Project Charter and then forgotten about.

A cornerstone of effective project management is to understand how much effort has been expended and what tasks have been accomplished, and then to use that information to guide completion of the project and to publish status reports that can be trusted. Project management is a closed loop, one popular model is the PDCA (Plan Do Check Act) cycle.

Check refers not only to the expected output, but also to the process – whether resources are being consumed as expected, whether risks remain acceptable, if schedule and cost-to-complete forecasts are still reasonable and in budget, etc.

For small enterprises, collecting information on effort typically means timesheets. Project infrastructure can sometimes be leveraged for metrics, such as a software bug tracker or a sprint planning tool, but this generally requires a large number of datapoints before being accurate enough for project management purposes. For SMEs with relatively few team members on a project, the ubiquitous timesheet will be the simplest and least intrusive method of collecting project effort metrics. Since many organizations require timesheets anyway for financial accountability, the additional work to also collect information useful project management need not be significant if done in the right way.

I’m working on a series of blog posts on SME product development project management, and researched the state of open source timesheet applications for use in a strawman based on a Swift Construction Company product development project. You’ll find out later which application I selected, but until then here the potential candidates I found.

]project-open[

]project-open[ is a fully featured portfolio project management suite. However, unfortunately with great power also comes significant complexity and in brief use I was unable to create a simple project and submit a timesheet. Commercial support is available, and the project co-founder walked me through some impressive basic functionality in a personal webinar.

ProjeQtOr

ProjeQtOr is a fully featured project management suite with a twist – with ProjeQtOr you  also get “all the tools that will ease to ensure conformity to any Quality Management System, effortlessly and without any extra too”. This approach has a lot of merit. Issues are issues whether they relate to a product in production or the execution of a project task, and investigating a non-conformance is just as much a project as is development of a new product or upgrading IT infrastructure.

qdPM

I used qdPM for several months to record effort for a personal project. qdPM is a freemium-type product, and the community version is licensed using the Open Source license. It is a professional grade product.

To me, qdPM seemed to suit product support more than project management, and includes top-level menu items for Tickets, Discussions, and Software Versions. Entering time spent on a task is done by creating a comment, and traditional project management such as cost vs time are not readily available.

timeEdition

timeEdition appears best suited for a single individual to track their personal project time, rather than actual project management. Although it appears to be commercial proprietary software from the website, I found a source code on Sourceforge using an open source license (see timeEdition Sourceforge project).

TimeTracker

TimeTracker lives up to its claim of being a simple, easy to use, open source, web-based time tracking application. After experimenting with it for a while, my only complaints are that tasks are not inherently project-specific, which could make task management overwhelming if you have a large number of projects, each with a large number of tasks. However, projects specify which tasks they include, so the task list is still manageable from a user’s perspective. 

TimeTrex

TimeTrex has a flashy website, but at heart is a traditional time-card system for scheduling and tracking task-based employees, not managing projects. You can download TimeTrex Community v9.1.3 from the TimeTrex project on Sourceforge if you don’t want to provide your email address using the TimeTrex website.

Additional Applications

I found another of other applications as well, but for one reason or another I didn’t have the opportunity to investigate further, or on cursory glance they didn’t seem suitable (remember, my original goal was a simple easy to use timesheet, not necessarily project management).

Watch for the start of my posts on project management to learn which application I selected for a Swift Construction Company strawman.

Cheers!

Time, Complexity, and Cost – but where is Risk?

There is a popular saying within the project management community:

Time, Cost, Quality, Pick Two.

It means two factors can be controlled if the third can be left uncontrolled, or in other words, you can’t have it all. Of course, this is a simplistic view of a potentially complex set of activities, but it is pragmatic and generally found to hold true. However, where does Risk enter in the equation?

First, what is risk? As risk in a project increases, so does the likelihood of the following:

  • Expectations will be viewed as optimistic and unrealistic in hindsight.
  • The project will exceed schedule and cost forecasts.
  • Product quality and customer approval will be lower than anticipated.
  • Production costs will be greater than anticipated.

Risk is primarily a function of complexity and time. Make the project more complex without increasing the time available and the risk of failure increases exponentially. Constrain the time available without reducing scope and the risk of failure increases exponentially. Get the idea? It’s really more of a guideline than a rule though.

When time is not the limiting factor, there will be enough time to figure it out, whatever it is. When there isn’t enough time, decisions will understandably be made based on missing and incorrect information (i.e. speculation), which can result in more work later to correct a bad decision. Additional schedule delays and cost overruns increase project stress, which increases risk, and if left uncorrected may result in the project’s collapse.

Developing a new product is an inherently risky activity, although achieving high-risk goals generally brings greater rewards – otherwise there would be no incentive to accept the risk. However, even if risk cannot be avoided it can be mitigated. Don’t accept unreasonable risk in your projects, and consider moving any very-high-risk tasks into a precursor research project to set appropriate expectations. Also ensure significant risks are well understood by project stakeholders. In a well managed and transparent project there can be no blame, and stakeholders share the consequences of the constraints they set and the risks that were accepted.

There is no place for wishful thinking in project management, and always have a Plan B ready at hand should an activity not execute as expected.

Cheers,
Dale