Engineering Manager and Consultant
Of interest to business enterprises.
Install webERP on Apache 2.4 and MariaDb 10.0.
#2. Product Lifecycle Management (PLM) using webERP
Create parts, identify vendor, configure unit-of-measure, create bill-of-materials.
Issue purchase order, receive stock, make payment.
#4. Manufacturing using webERP
Create work order, receive output goods, close work order.
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.
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.
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.
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.
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.
Remember, if it’s important, seek professional guidance!
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[ 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 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.
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 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 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 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.
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!
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:
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