SlideShare a Scribd company logo
Clientcentered Software Development The Cofoss
Approach Tucker download
https://ebookbell.com/product/clientcentered-software-
development-the-cofoss-approach-tucker-10502608
Explore and download more ebooks at ebookbell.com
Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Clientcentered Business Consulting The Power Of Psychological
Understanding Federico Addimando
https://ebookbell.com/product/clientcentered-business-consulting-the-
power-of-psychological-understanding-federico-addimando-52456066
The Clientcentered Law Firm Jack Newton
https://ebookbell.com/product/the-clientcentered-law-firm-jack-
newton-49427624
Contributions To Clientcentered Therapy And The Personcentered
Approach Nathaniel J Raskin
https://ebookbell.com/product/contributions-to-clientcentered-therapy-
and-the-personcentered-approach-nathaniel-j-raskin-48402310
The Art Of Hypnotherapy Mastering Client Centered Techniques 4th
Edition C Roy Hunter
https://ebookbell.com/product/the-art-of-hypnotherapy-mastering-
client-centered-techniques-4th-edition-c-roy-hunter-48880426
Polyvagalexercises For Safety And Connection 50 Clientcentered
Practices Norton Series On Interpersonal Neurobiology Deb Dana
https://ebookbell.com/product/polyvagalexercises-for-safety-and-
connection-50-clientcentered-practices-norton-series-on-interpersonal-
neurobiology-deb-dana-43835790
Technology Tools For Todays Highmargin Practice How Clientcentered
Financial Advisors Can Cut Paperwork Overhead And Wasted Hours David J
Drucker
https://ebookbell.com/product/technology-tools-for-todays-highmargin-
practice-how-clientcentered-financial-advisors-can-cut-paperwork-
overhead-and-wasted-hours-david-j-drucker-4313006
Adaptive Coaching The Art And Practice Of A Clientcentered Approach To
Performance Improvement Terry R Bacon
https://ebookbell.com/product/adaptive-coaching-the-art-and-practice-
of-a-clientcentered-approach-to-performance-improvement-terry-r-
bacon-1716678
The Heart Of Act Developing A Flexible Processbased And Clientcentered
Practice Using Acceptance And Commitment Therapy Robyn D Walser
https://ebookbell.com/product/the-heart-of-act-developing-a-flexible-
processbased-and-clientcentered-practice-using-acceptance-and-
commitment-therapy-robyn-d-walser-42758798
Gender Identity And Faith Clinical Postures Tools And Case Studies For
Clientcentered Care Mark A Yarhouse
https://ebookbell.com/product/gender-identity-and-faith-clinical-
postures-tools-and-case-studies-for-clientcentered-care-mark-a-
yarhouse-46368840
Clientcentered Software Development The Cofoss Approach Tucker
Clientcentered Software Development The Cofoss Approach Tucker
Client-Centered Software
Development
The CO-FOSS Approach
Clientcentered Software Development The Cofoss Approach Tucker
Client-Centered Software
Development
The CO-FOSS Approach
Allen B. Tucker
CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742
⃝
c 2019 by Taylor & Francis Group, LLC
CRC Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works
Printed on acid-free paper
International Standard Book Number-13: 978-1-138-58384-9 (Hardback)
This book contains information obtained from authentic and highly regarded sources. Rea-
sonable efforts have been made to publish reliable data and information, but the author and
publisher cannot assume responsibility for the validity of all materials or the consequences
of their use. The authors and publishers have attempted to trace the copyright holders of
all material reproduced in this publication and apologize to copyright holders if permis-
sion to publish in this form has not been obtained. If any copyright material has not been
acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, re-
produced, transmitted, or utilized in any form by any electronic, mechanical, or other means,
now known or hereafter invented, including photocopying, microfilming, and recording, or in
any information storage or retrieval system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access
www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Cen-
ter, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-
for-profit organization that provides licenses and registration for a variety of users. For
organizations that have been granted a photocopy license by the CCC, a separate system
of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trade-
marks, and are used only for identification and explanation without intent to infringe.
Library of Congress Cataloging-in-Publication Data
Names: Tucker, Allen B., author.
Title: Client-centered software development : the CO-FOSS approach /
Allen B. Tucker.
Description: Boca Raton, FL : CRC Press/Taylor & Francis Group, [2019]
| Includes index.
Identifiers: LCCN 2019010378| ISBN 9781138583849 (hardback : acid-free
paper) | ISBN 9780429506468 (ebook)
Subjects: LCSH: Application software--Development. | Computer software
industry--Customer services. | Consumer satisfaction.
Classification: LCC QA76.76.D47 T839 2019 | DDC 005.3--dc23
LC record available at https://lccn.loc.gov/2019010378
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the CRC Press Web site at
http://www.crcpress.com
To Meg,
my inspiration
and lifelong partner
Clientcentered Software Development The Cofoss Approach Tucker
Contents
List of Figures xvii
List of Tables xxiii
Foreword xxv
Preface xxix
Acknowledgments xxxv
About the Author xxxvii
Chapter 1 ■ The Journey 1
1.1 SOFTWARE 1
1.2 SOFTWARE DEVELOPMENT MODELS 3
1.2.1 Serial Development 3
1.2.2 Agile Development 4
1.2.3 CO-FOSS Development 5
1.2.4 Software Customization: A Continuum 7
Custom Software 7
Off-the-Shelf Software 8
Custom Software with Off-the-Shelf Components 9
1.3 SOFTWARE LICENSING 9
1.3.1 Proprietary Licensing 9
1.3.2 Open Source Licensing 10
1.3.3 FOSS Origins and Impact 13
FOSS Worldwide 16
Terminology: OSS, FOSS, FLOSS, H/FOSS, and
CO-FOSS 18
vii
viii ■ Contents
1.4 SOFTWARE ARCHITECTURES 19
1.4.1 Software Frameworks 19
1.4.2 Web Servers and Bundles 21
1.5 NEW VS MATURE OPEN SOURCE PROJECTS 22
1.5.1 Maturity Assessment 23
1.5.2 Incubation 24
Community 25
Bug Tracking 27
1.6 INTO THE WEEDS 28
1.6.1 To the Instructor 29
1.6.2 To the Student 31
1.6.3 To the Client 32
1.6.4 To the Developer 33
1.7 SUMMARY 33
1.8 MILESTONE 1 34
Section I Organization Stage
Chapter 2 ■ Finding a Client and a Project 37
2.1 CLIENT ACTIVITIES AND SOFTWARE NEEDS 39
2.1.1 The Current Process and Existing Software 41
2.1.2 New Software to Fit a New Need 44
2.2 DOMAIN ANALYSIS 45
2.2.1 Requirements Gathering 48
2.2.2 User Stories 49
2.2.3 Use Cases 50
Unified Modeling Language 52
Writing an Effective Use Case 53
2.3 SOFTWARE DESIGN 55
2.3.1 System and Performance Requirements 55
2.3.2 Software Architecture 57
Layering, Cohesion, and Coupling 57
Domain Class Layer 61
Database Layer 61
User Interface Layer 63
2.3.3 Software Security 63
2.3.4 Encouraging Code Reuse 65
Contents ■ ix
2.4 THE DESIGN DOCUMENT 66
2.4.1 Overall Structure 67
2.4.2 Variations 68
2.5 THE SANDBOX 69
2.6 SUMMARY 70
2.7 MILESTONE 2 70
Chapter 3 ■ Defining the Course 71
3.1 SOFTWARE PROJECT ELEMENTS 71
3.1.1 Collaboration Tools 72
3.1.2 Development Platform 73
3.1.3 Project Hosting 74
3.1.4 The Version Control System 75
3.1.5 Sandbox and Live Versions 77
3.1.6 Reading, Writing, and Documenting Code 79
3.1.7 Unit Testing 82
Unit Testing Tools 84
3.1.8 User Help 85
3.2 THE COURSE 86
3.2.1 The Classroom 87
3.2.2 Team Formation and Dynamics 88
3.2.3 Scheduling and Milestones 90
3.2.4 Ensuring Progress 92
3.2.5 The Syllabus 93
3.2.6 Assignments and Grading 95
3.2.7 Alternatives: The Two-Semester Software Projects
Course 97
3.3 SUMMARY 98
3.4 MILESTONE 3 98
Section II Development Stage
Chapter 4 ■ Project Launch 101
4.1 THE TEAM 101
4.1.1 Team Dynamics 103
x ■ Contents
4.1.2 Asynchronous Communication 105
Aside: Mature FOSS Projects 106
4.1.3 Synchronous Communication 107
4.1.4 Shared Documents 108
4.2 THE DEVELOPMENT TOOLS 109
4.2.1 Programming Languages 109
JavaScript 110
Python 110
Java 111
Ruby 111
PHP 111
HTML and CSS 111
Other Languages 112
4.2.2 Software Platforms 112
The Apache/MySQL/PHP Server 113
Server-Side Java 114
Python 114
Ruby 114
4.2.3 IDEs for Development 114
Eclipse IDE 115
Python IDEs 116
Ruby IDEs 116
Java IDEs 116
Choosing and Installing an IDE 117
4.2.4 Working with the VCS 117
4.3 THE PRODUCT 122
4.3.1 Reading the Design Document 122
Identify Classes and Modules 124
Identify Instance Variables 124
Identify Methods and Functions 124
4.3.2 Reading the Code 126
Start from the Top 126
Look for Classes with Unique Keys 127
Avoid the Temptation to Edit the Code 128
4.3.3 Reading and Writing Code 129
4.3.4 Code Reuse 130
4.3.5 Licensing 131
Contents ■ xi
4.4 SUMMARY 132
4.5 MILESTONE 4 132
Chapter 5 ■ Domain Class Development 133
5.1 CODING THE DOMAIN CLASSES 134
5.1.1 Reusing External Legacy Code 134
5.1.2 Reusing Internal Legacy Code 136
5.1.3 Coding a Domain Class from Scratch 137
5.1.4 Adding Functionality: Constructor and Getters 138
5.2 SOFTWARE TESTING 139
5.2.1 Test Case Design 141
5.2.2 Unit Testing Frameworks 142
5.2.3 Unit Testing the Homeroom Domain Classes 146
5.2.4 Unit Testing the Homebase Domain Classes 147
5.2.5 Code Synchronization and Integration Testing 151
5.3 DEBUGGING AND REFACTORING 154
5.3.1 Debugging 154
5.3.2 Identifying Bad Smells 156
Aside: Using Software Metrics 158
5.3.3 Refactoring 159
5.4 CLIENT REVIEW AND ISSUE TRACKING 162
5.4.1 Client Review 162
5.4.2 Issue Tracking 163
5.5 SUMMARY 164
5.6 MILESTONE 5 165
Chapter 6 ■ Database Development 167
6.1 DATABASE PRINCIPLES 168
6.1.1 Relations and Tables 169
Table Naming Conventions 170
6.1.2 Queries 172
6.1.3 Normalization 173
6.1.4 Keys 175
6.1.5 Concurrency Control 176
xii ■ Contents
6.2 DATABASE ACCESS 177
6.2.1 Connecting the Program to the Database 178
6.2.2 Table Creation and Dropping 179
6.2.3 CRUD Functions 181
Create: Inserting Rows into a Table 182
Retrieving Rows from a Table 182
Update: Altering Rows in a Table 184
Delete: Removing Rows from a Table 185
6.2.4 Database Security 185
6.2.5 Database Integrity 187
6.2.6 Adding a Database Abstraction Layer 190
6.3 DATABASE TESTING 191
6.3.1 Testing the dbShifts.php Module 191
6.3.2 Testing the dbPersons.php Module 193
6.3.3 Testing the dbBookings.php Module 195
6.3.4 Testing the dbRooms.php Module 196
6.3.5 Integration Testing: Persons, Bookings, and
Rooms 197
6.4 CLIENT REVIEW AND ISSUE TRACKING 200
6.4.1 Client Review 200
6.4.2 Issue Tracking 201
6.5 SUMMARY 205
6.6 MILESTONE 6 205
Chapter 7 ■ User Interface Development 207
7.1 PRINCIPLES 208
7.1.1 Model-View-Controller Pattern 209
MVC Example 1: Editing a Shift in Homebase 211
MVC Example 2: Editing a Person in Homeroom 212
MVC Example 3: Editing a Stop in Homeplate 213
7.1.2 Linkages among MVC triples 214
7.1.3 User-Level Security 216
User Login and Password Encryption 216
User Access Levels 218
Enforcement of Access Levels 218
Contents ■ xiii
7.1.4 Protection against Outside Attacks 219
Avoiding SQL Injection Attacks 219
Avoiding Cross-Site Scripting Attacks 220
7.2 PRACTICE 221
7.2.1 Sessions, Query Strings, and Global Variables 221
7.2.2 Working with Scripts and HTML 223
Scripting Example 1: Editing a Shift 224
Scripting Example 2: Managing a Sub Call List 226
7.2.3 Reading Deeply 227
7.2.4 Using JavaScript and jQuery UI to Improve the
User Interface 231
7.2.5 Responsive User Interfaces 234
Responsive user interface design 236
7.3 TESTING, DEBUGGING, AND REFACTORING 238
7.3.1 Testing a User Interface 240
Organizing the Testing Process 243
7.3.2 Refactoring: Removing a Layering Violation 243
7.4 ADDING A NEW FEATURE: ALL LAYERS IMPACTED 246
Changing the Edit Person MVC Triple 247
Changing the Search for Persons MVC Triple 248
Changing the Schedule Person MVC Triple 249
Changing the Edit Shift MVC Triple 250
Changing the Sub Call List MVC Triple 251
7.5 CLIENT REVIEW AND ISSUE TRACKING 252
7.5.1 A User Interface Bug 253
7.5.2 A Multi-Layer Bug 256
7.6 SUMMARY 258
7.7 MILESTONE 7 259
Chapter 8 ■ Preparing to Deploy 261
8.1 TECHNICAL WRITING 261
8.1.1 Writing for an Audience 262
8.1.2 Standards for Writing Quality 264
8.2 USER DOCUMENTATION 267
8.2.1 User Manuals, FAQs, and Demo Versions 267
Example: Firefox User Manual 269
xiv ■ Contents
Example: OpenMRS FAQ and Demo 270
Example: Homebase Demo 270
8.2.2 On-Line Help 271
8.2.3 Example: Homebase On-Line Help 273
Context-Sensitive Help 273
Help Table of Contents and Navigation 274
Help System Architecture 275
8.3 OTHER USER SUPPORT 278
8.3.1 User Training 278
8.3.2 Feedback Surveys 279
8.3.3 Final Presentations 280
8.4 CLOSURE FOR STUDENTS 281
8.4.1 Self-Assessment 281
8.4.2 Leveraging the CO-FOSS Experience 281
8.5 SUMMARY 282
8.6 MILESTONE 8 282
Section III Deployment Stage
Chapter 9 ■ Continuing the Journey 287
9.1 TRANSITIONING TO PROFESSIONAL SUPPORT 287
9.1.1 The Hand-Off 288
9.1.2 Case Studies 289
Homebase Hand-Off and Support 289
RMHP-Homebase Hand-Off and Support 289
Homeroom Hand-Off and Support 290
Homeplate Hand-Off and Support 290
BMAC-Warehouse Hand-Off and Support 290
9.2 PROJECT EVALUATION AND CODE RELEASE 291
9.2.1 Potential New Clients 291
Volunteer and Resource Scheduling 291
Food Rescue and Redistribution 292
Agricultural Operations 293
9.2.2 Licensing Choices 293
9.2.3 Project Hosting Alternatives 294
GitHub 294
Contents ■ xv
GitLab 294
Bitbucket 295
SourceForge 295
9.2.4 Maturity Assessment 296
9.3 SOFTWARE MAINTENANCE AS A COMMUNITY ACTIVITY 298
9.3.1 Fixing Bugs: A Case Study 298
User-Developer Discussion 299
Debugging Activities 299
Developer-Developer Discussion 301
Closure 303
9.3.2 Software Maintenance: A Multi-Year Developer
Perspective 304
Homebase Maintenance: 2010-2018 304
Homeplate Maintenance: 2012-2018 305
Homeroom Maintenance: 2013-2018 306
BMAC-Warehouse Maintenance: 2015-2018 307
RMHP-Homebase Maintenance: 2015-2018 308
9.4 CREATING A FORUM 308
9.4.1 Example: Wordpress Support Forums 309
9.4.2 Example: Firefox Forums 311
9.4.3 An Example Forum Exchange 312
9.5 EVOLVING INTO A DEMOCRATIC MERITOCRACY 312
9.5.1 Incubation 313
9.5.2 Organization 314
9.5.3 Task-Specific Roles 316
9.5.4 Oversight 317
9.5.5 Decision Making and Conflict Resolution 318
9.5.6 Domain Constraints 319
9.5.7 FOSS Project Foundations 320
9.6 SUMMARY 320
9.7 MILESTONE 9 321
9.8 ENDING THE JOURNEY 321
BIBLIOGRAPHY 323
INDEX 327
Clientcentered Software Development The Cofoss Approach Tucker
List of Figures
1 The Triad. xxxi
2 The Three Stages of CO-FOSS Development. xxxi
1.1 The serial (waterfall) software development model. 4
1.2 An agile software development cycle. 5
1.3 The CO-FOSS software development model. 6
1.4 Relationships among common FOSS licenses. 12
1.5 Stand-Alone Computing. 19
1.6 Client-Server Framework. 20
1.7 Cloud Computing Framework. 20
1.8 Life cycle of a bug, from Bugzilla documentation, p 9. 28
2.1 RMH guest referral form (prior to 2011). 46
2.2 RMH guest registration card (prior to 2011). 47
2.3 RMH guest room log (prior to 2011). 48
2.4 Homeroom use cases. 53
2.5 Layered Architecture (↔ denotes information flow and → de-
notes control flow). 58
2.6 Layered architecture of Homeroom. 59
2.7 Some of the initial domain classes for Homeroom. 61
2.8 dbRooms table structure in Homeroom database. 62
2.9 Room view screen draft for Homeroom. 64
2.10 Login Form for Restricting Homeroom Access. 64
3.1 The sandbox version: client-developer interaction. 78
3.2 Example code from Homeroom. 79
3.3 Output of the example code in Figure 3.2. 80
3.4 Inserting comments into the 2015 version of the Homebase
Shift class. 81
xvii
xviii ■ List of Figures
3.5 PHP documentation generated for the 2008 version of the
Homebase Shift class. 83
3.6 Some of the functions in the Shift class for unit testing. 84
3.7 Elements of a unit test for the Shift class. 85
3.8 Results of running the TestShift unit test. 86
3.9 Form for filling a vacancy on a shift. 87
3.10 Help screen for filling a vacancy. 88
3.11 Assignment 3 in the BMAC-Warehouse project. 96
4.1 Developing Homeroom with the Eclipse IDE. 116
4.2 The code synchronization problem. 119
4.3 Resolving the problem: Copy-modify-merge. 120
4.4 Git Menu Options (on right) from within an Eclipse IDE. 121
4.5 Documentation practice using indented blocks and control
structures. 130
4.6 Showing the open source license notice in the user interface. 131
4.7 Displaying the open source license notice in the source code. 131
5.1 Reusable Homebase Code in 2008. 136
5.2 Adapting the Code for Reuse in Homeroom in 2011. 137
5.3 Original Booking Class for Homeroom in 2011. 138
5.4 Revised Booking class for Homeroom in 2013. 139
5.5 Room class constructor and getters for Homeroom. 140
5.6 Test Suite in the Homeroom tests Directory. 143
5.7 Results of running a Test Suite. 143
5.8 A Unit Test for the Room Class in Homeroom. 144
5.9 Reporting a Unit Test Failure. 145
5.10 Setter Functions for the Room Class in Homeroom. 146
5.11 Partial unit test for the Booking Class in Homeroom. 148
5.12 The 2013 unit test for the Shift class. 149
5.13 The 2015 unit test for the Shift class. 150
5.14 New ApplicantScreening Class Added to Homebase in 2015. 151
5.15 New ApplicantScreening Unit Test added in 2015. 152
5.16 Interdependencies among Classes for Integration Testing. 153
5.17 A Recent GitHub Issue List for the Homeplate Project. 155
5.18 Example bad smell—duplicate code. 156
5.19 Example bad smell removal. 157
List of Figures ■ xix
5.20 Searching the code base for all references to the get_address
function. 160
6.1 A few rows in the dbDates table. 170
6.2 Homebase Shift class instance variables. 171
6.3 Attribute names and types in the dbShifts table. 172
6.4 The entries in the dbShifts table for August 6, 7, and 8, 2018
in Portland. 172
6.5 Connecting to the Homebase database. 179
6.6 Template for MySQLi table creation. 180
6.7 Creating the dbDates table in the Homebase database. 181
6.8 The phpMyAdmin tool for managing a MySQLi database. 181
6.9 Deleting a date from the dbDates table. 188
6.10 Retrieving a person from the dbPersons table in Homeroom. 189
6.11 A unit test for the dbShifts module. 192
6.12 Instance variables for the Person class in Homeroom. 193
6.13 A unit test for the dbPersons module. 194
6.14 Instance variables for the Booking class in Homeroom. 195
6.15 Portions of a unit test for the dbBookings.php module. 196
6.16 Instance variables for the Room class in Homeroom. 197
6.17 A unit test for the dbRooms.php module. 198
6.18 An integration test for dbPersons.php, dbBookings.php, and
dbRooms.php. 199
6.19 The first 6 issues posted for the 2015 Homebase project. 201
6.20 Simple framework for posting a new issue. 202
6.21 Form for posting a new issue on a GitHub project. 203
7.1 The Model-View-Controller pattern. 210
7.2 The Edit Shift view in Homebase. 211
7.3 The Person Edit view in Homeroom. 212
7.4 The Stop view in Homeplate. 213
7.5 The main menu views in (a) Homebase, (b) Homeroom, and
(c) Homeplate. 214
7.6 Part of the view and controller for the main menu MVC in
Homebase. 215
7.7 The View and Controller for the Homebase login form. 217
7.8 Ensuring security in Homebase using $_POST and $_SESSION
variables. 219
xx ■ List of Figures
7.9 Controlling navigation using $˙POST variables. 224
7.10 Excerpts from editShift.php view and controller module. 225
7.11 Underlying view and controller for managing a SubCallList. 227
7.12 Using the SubCallList form. 228
7.13 Code snippet for removing a person from a Shift. 230
7.14 Essential steps for deleting a Shift from the dbShifts table. 231
7.15 Essential steps for inserting a Shift into the dbShifts table. 232
7.16 Coding calendar date using HTML selects. 233
7.17 Coding calendar date using a jQuery UI datepicker widget. 234
7.18 A Responsive user interface. 235
7.19 The Homeplate Mobile home screen. 236
7.20 A responsive user interface view. 238
7.21 HTML code underlying part of the view in Figure 7.20. 239
7.22 The Calendar view inside Homebase Use Case 4. 241
7.23 Layering Violation: a user interface module directly querying
the database. 244
7.24 Layering Violation fixed and bad smell removed. 246
7.25 Showing a person’s status in the Edit Person view. 248
7.26 Coding to show a person’s status in the Edit Person view. 248
7.27 Updating a database entry with the new status field. 249
7.28 Searching for “applicant” status. 249
7.29 Search results for status = “applicant”. 250
7.30 searchPeople.php code for selecting a person’s type. 250
7.31 Listing only “active” volunteers when filling a vacancy. 251
7.32 Changing editMasterSchedule.php to list “active” volunteers. 251
7.33 Selecting only active volunteers for filling a calendar vacancy. 252
7.34 Code for selecting only active volunteers. 252
7.35 Issues 7-16 posted for the 2015 Homebase project. 254
7.36 Locating a bug in the calendar.php module. 255
7.37 The process_edit_notes function inside calendar.inc. 257
7.38 Locating a bug in the dbDates module. 258
8.1 First page of the Firefox user manual, including Help link. 269
8.2 The Introductory OpenMRS FAQ List. 270
8.3 The OpenMRS on-line demo. 271
8.4 The Homebase on-line demo. 272
8.5 Context-sensitive help for the search page. 273
List of Figures ■ xxi
8.6 The first two steps in the Searching for People help page. 274
8.7 Enlarged thumbnail in Step 2 of Searching for People. 274
8.8 The on-line help table of contents in Homebase. 275
8.9 Integrating help pages within the code base. 276
8.10 HTML code for Step 2 in the help file searchPersonHelp.inc.php. 277
9.1 Reproducing the bug. 300
9.2 Locating the defect. 300
9.3 Designing the fix. 301
9.4 Testing the fix: editing a person. 302
9.5 Points of access to the Wordpress forums. 310
9.6 Snapshot of the Installing Wordpress Forum. 310
9.7 Accessing the Firefox user forum. 311
9.8 Organizational levels in the Sahana project. 317
Clientcentered Software Development The Cofoss Approach Tucker
List of Tables
2.1 Process a Referral. 54
2.2 Overall Structure of a Design Document. 67
3.1 A few PHPDoc Tags and their Meanings. 82
3.2 Example Course Syllabus Schedule: Spring 2015 Semester. 94
4.1 Overall Structure of the Homeroom Code Base. 127
6.1 Relations in SQL Queries. 173
6.2 Redesigning the dbShifts table to improve normalization. 175
6.3 Programming Language Database Extensions for SQL. 178
6.4 Common Attribute Types in MySQLi Tables. 180
7.1 CRUD Functions in the dbShifts module. 230
7.2 The three views in the Editing the Calendar use case. 240
7.3 MVC steps for adding a new feature. 247
8.1 Homebase User Questionnaire and Results. 279
8.2 Agenda for a Final Presentation. 280
xxiii
Clientcentered Software Development The Cofoss Approach Tucker
Foreword
Client-Centered Software Development: The CO-FOSS Approach provides a
much needed guide and resource for undergraduate software development
or capstone courses that seek to engage students in a real-world software-
development project.
Such a course offers unique and daunting challenges. As someone who has
taught such a course intermittently over my 30+ year career, the goal was
always to give students a real sense of what software development is like. But
the challenges are many. How do you identify a project that can be done and
done well in a 14-week semester? How do you manage teams of undergraduate
CS majors, with different skill sets and motivations? What combination of
platforms and software tools can be used effectively under such constraints?
How do you evaluate student effort and contributions? What happens to the
“product” once the semester ends? These are just some of the issues.
In this book, Allen Tucker has laid out a well-tested and practical model for
addressing these challenges. The development approach is called CO-FOSS,
which stands for client-oriented software development using free and open
source software. The class project involves developing and deploying a soft-
ware product for an actual client, which is typically a local non-profit or-
ganization that needs mission critical software but cannot afford to hire a
professional software-development company. The software platform and tools
used in the project are all freely available and openly licensed. The book is full
of instructive examples that cover all of the parts and stages of a substantial
software-development project. It ends with a practical and innovative model
for supporting the student-built product after the semester has ended. This
is very important – many of the software-development projects one finds in
undergraduate courses end up sitting on shelves.
It’s great to see the evolution of the type of FOSS-development course
that this book describes. Ten years ago or so, I and other faculty tried to
organize such courses under the banner of the Humanitarian Free and Open
Source Software project (HFOSS). The idea then was to get students involved
with existing FOSS projects, particularly those that served “humanitarian”
purposes. The goal was to teach students about FOSS development – some-
thing that was not typically part of the CS curriculum at the time – by
getting them engaged as contributors to some real FOSS projects. We collab-
orated with the Sahana project (a disaster management system), OpenMRS (a
medical records system), GNOME (Linux-based accessibility software), TOR
xxv
xxvi ■ Foreword
(privacy-based browser software), the Mozilla project, and others. While we
had many successes, and while many students made significant contributions
to these projects, the logistics of managing collaboration with such projects
within a one-semester course proved difficult. The CO-FOSS model addresses
the challenges that the HFOSS approach faced in creative and practical ways.
This book shows that you really can get students involved in meaningful FOSS
development in a one-semester course.
The book is organized into three main parts. The Organization Stage sec-
tion is written primarily for the instructor and provides practical advice on
identifying a client and creating a plan for a doable software product that
would help that client, as well as constructing the syllabus for the course. A
key part of the syllabus is a carefully thought-out sequence of milestones that,
if followed, will lead to successful completion of the project.
The Development Stage section is written primarily for students and is
meant to be read and followed during the semester. It concisely covers all
of the main elements of software development with numerous practical ex-
amples: creating development teams, object-oriented design, database design,
user-interface design and development, software documentation, and support.
Among other things, this section has brief but authoritative discussions of:
• FOSS licensing
• The LAMP, MAMP, and WAMP server stack – i.e., Linux, Apache,
MySQL, and PHP
• Software hosting (e.g., GitHub) and issue tracking
• Communication software such as Skype and Slack
• Creating and using unit tests for all parts of the software
• Principles of Model-View-Controller design
• Effective debugging tools and strategies
• IDEs for various programming languages, including PHP, Python, Ruby,
and Java
• Database essentials, including normalization and CRUD functions
• Principles of software security
• Writing useful documentation and user-help features
Each of these topics is supported with helpful examples, including many
code snippets, taken from successful CO-FOSS projects that Allen and oth-
ers have conducted at various undergraduate institutions, including Bowdoin
College, Dickinson College, University of New Hampshire, Whitman College,
and others. Importantly, the projects created at these schools are hosted on
Foreword ■ xxvii
GitHub, and available to be used as models or even templates, depending on
the type of software product a client needs.
The Deployment Stage section describes how to transition the product
from the classroom to professional support so that the product can live on.
An important feature of this section is the role played by the Non-Profit
FOSS Institute (NPFI), an organization started by Allen that provides help
in identifying and supporting professionals who can realistically be expected
to host the software and manage its ongoing debugging and support. When
no such professionals can be found, NPFI shoulders some of these tasks itself.
This is an incredibly powerful resource, which has the potential to make all the
difference between a class project that dies once the class ends and a software
product that truly adds value to the client’s mission.
Some other important features of the book include:
• Milestones: Each of the nine chapters include a short list of milestones.
These serve both as a means of keeping the project on track, and also
as assignments that can serve as the basis for evaluating student work.
• Course organization: In addition to providing a template that can be
used to model the course syllabus, the book provides helpful ideas on
how to evaluate student work. Like other parts of the book, these have
the benefit of being based on courses that have tried and tested many
of the ideas in the book.
Designing and implementing a software-development course in an under-
graduate CS program can be intimidating. It exposes the instructor to risks
not found in other courses: Will he or she be able to manage the relationship
with the client? Will the students be able to create a quality piece of software,
and will they see it as an important education experience? Will the instructor
receive credit for taking such risks and going beyond the usual course expecta-
tions? On this last point, it is worth noting that more and more schools seem
to be encouraging “community involvement,” and many have set up centers
designed to serve as interfaces between town and gown. The model described
in this book would fit in well with such institutional initiatives.
This book provides a workable model that helps mitigate some of these
worries. The projects used as examples throughout the book serve as a proof
of concept for what can be done, and the book itself serves as a step-by-step
guide to getting it done. If you are considering an undergraduate software-
development course that teaches the principles of FOSS development, you
won’t go wrong by starting with this book.
Ralph Morelli
Professor of Computer Science (Emeritus)
Trinity College
Hartford, CT
April 20, 2019
Clientcentered Software Development The Cofoss Approach Tucker
Preface
Software development is a complex and dynamic field. Its complexity appears
in many forms – the sheer variety of software clients and applications, the
rapid evolution of software development tools, the wide range of skills among
professional developers, the rapid evolution of computing platforms, and the
diversity of strategies used to develop the software itself.
This book is about one particular strategy for software development called
the “CO-FOSS approach.” The term CO-FOSS is short for “Client-Oriented
Free and Open Source Software.” A project using the CO-FOSS approach aims
to develop a customized software product for a single client, either from scratch
or (more likely) by reusing open source components from prior projects.1
The client for a CO-FOSS project is typically a non-profit humanitar-
ian, educational, or public service organization, such as a Ronald McDonald
House, a local school system, a Habitat ReStore, a food distribution organiza-
tion, or a senior center. The key here is that the client has a genuine need for
new software that will streamline a mission-critical operation, such as volun-
teer calendar scheduling, inventory management, donation tracking, or room
scheduling.
The CO-FOSS approach has been evolving since 2008. It has been used
in intermediate and capstone undergraduate computing courses where teams
of students learned the principles of software development while they gained
practical experience implementing a real-world software product. The key dis-
tinction for CO-FOSS in this setting is that the software product itself is real:
the students are developing it for a real client, so both the risks and the re-
wards are high in comparison with a more traditional software development
course with no real product.
Organizing such a course requires an unusual effort by the instructor. Be-
cause some of this effort may be unrewarded by typical institutional measures
for excellence in teaching, the instructor must view the benefits of taking this
“outside the box” approach as worthwhile. Additional support for making this
1The term “CO-FOSS” was coined in a 2014 study by MacKellar, Sabin, and Tucker [25],
which discusses the results of using this approach in courses at three different types of
institutions. The original idea of “client-oriented FOSS” was presented in a 2011 book by
Tucker, Morelli, and de Silva [43], where it was contrasted with the idea of “community-
oriented FOSS.” While both ideas engage students with FOSS development, the latter
creates a more generic product that is not customized for a single client.
xxix
xxx ■ Preface
extra effort may come from the instructor’s home institution or from various
outside sources such as the Non-Profit FOSS Institute.2
Our experiences with the CO-FOSS approach have yielded the following
benefits:
1. Undergraduate computing students are uniquely motivated by commu-
nity service experiences that are embedded within their formal academic
training. Uniformly, they report great satisfaction when using their com-
puting skills to develop software that serves the larger community (e.g.
the page https://npfi.org/student_evaluations/ shows the com-
plete student evaluations for the software development course taught at
Whitman College in 2015).
2. Client organizations benefit by receiving free customized software that
directly supports their mission-critical activities. For example, the
Ronald McDonald House in Providence, RI received volunteer database
and scheduling software called Homebase developed by a 5-student
team in that 2015 Whitman College course (see https://npfi.org/
projects/the-rmhp-homebase-project/). That software is still in use
today.
3. The fact that a CO-FOSS product is free and open source software allows
any of its source code to be reused and refitted to suit the needs of a fu-
ture project. For example, the Homebase software mentioned above was
adapted from an earlier version developed in 2013 by Bowdoin Col-
lege students for the Ronald McDonald House in Portland, ME. Thus, an
open source license like the GNU General Public License or the Mozilla
Public License is an essential element of the CO-FOSS approach.
4. Students gain experience learning about key elements of the software
development process, including coding, testing, refactoring, and writing
user documentation, as they would in a conventional software devel-
opment course. However, these students also gain practical experience
by working within a team, communicating with a client, using a client-
centered development model, sharing a code base, and reusing legacy
code – experience that prepares them well for entry into the modern
software industry.
This book aims to provide instructors, students, clients, and professional
software developers with a roadmap to guide them through the development
of a new CO-FOSS product from conceptualization to deployment. We use
2Throughout this book, any word or phrase that appears in typewriter font represents
a link to a Web page that provides more details. Of course, those links work only for the
e-book version. Readers using the print version should be able to locate most of these Web
pages by doing a Google search for that word or phrase.
Preface ■ xxxi
our own experiences with this approach to illustrate each step in the process,
detailing its technical elements, its methodologies, and its outcomes.3
The CO-FOSS approach views each project as having three connected el-
ements that form a triad, as pictured in Figure 1. The student team is one
element of the triad, the client is the second, and the professional developer
is the third. The goal of a triad is to design, implement and deploy a cus-
tomized software product that supports a specific mission-critical activity of
the client.4
FIGURE 1 The Triad.
The instructor is involved in all three ele-
ments of a CO-FOSS project. The instructor
organizes it, leads the student team through
project development, and delivers the completed
software product to the professional. The stu-
dents, who are intermediate-level computing ma-
jors, develop the software using both the require-
ments document and a client-centered approach.
The professional installs the completed software
on the client’s server, and then provides ongoing
support thereafter.5
The project has three stages: a 2-month or-
ganization stage, a 3-month development stage, and a 1-month deployment
stage, as shown in Figure 2.
FIGURE 2 The Three Stages of CO-FOSS Development.
So the instructor provides the glue that holds these three stages together, as
outlined below:
3All the examples in this book use the PHP/Javascript/MySQL/HTML platform, since
that is the platform on which our own CO-FOSS projects were built. So while instructors
may find the organizational aspects of this book to be useful, this book may be supplemented
by reference materials that uses a different platform, such as Django or Rails.
4Absent the student team, a CO-FOSS product can always be designed, implemented,
and deployed by a professional developer working directly with the client.
5Because the requirements and the design document are prepared during the organiza-
tion stage, the course itself should be properly labeled “software development” rather than
“software design.”
xxxii ■ Preface
1. During the organization stage, the instructor identifies the client’s
mission-critical software need, and then develops the requirements for a
software product that will fulfill that need. This includes eliciting an ini-
tial set of use cases from the client, developing an initial design document
and course syllabus that has an implementation timeline embedded, and
forming the student team.
2. During the development stage, the instructor, student team, and client
representative use a client-centered process to create a software product
that fulfills the requirements. That is, in a 1-semester course, the team
iteratively develops the product and refines the requirements, taking
into account the client’s feedback at each iteration.6
3. During the deployment stage, the instructor turns the product over to
the developer who installs the product on the client’s server (website).
Here, the developer and the client also collaborate to iron out any linger-
ing issues for the product and agree on a long-term support plan going
forward.7
To introduce the CO-FOSS approach, this book has an introductory chap-
ter followed by three Parts. The introductory chapter provides an overview of
software, open source licensing, and major software development methodolo-
gies. Everyone should read this chapter first and complete Milestone 1 at
the end of the chapter before continuing.
Each Part thereafter explores one of these three stages by sharing our
knowledge of designing, developing, and deploying a CO-FOSS product using
the triad as an organizational framework.
Part I is written mainly for the instructor and secondarily for the client.
It covers the details of finding a client and a CO-FOSS product to be de-
veloped, defining that product’s requirements, and organizing a course in
which students can develop the product. The instructor should complete
Milestones 2 and 3 before continuing to Part II.
Part II comprises the bulk of the book and is written mainly for the in-
structor and the students. It covers the principles and practice of client-
centered software development, with many examples from CO-FOSS
projects that our students have completed in recent years. The chapters
6We know of several CO-FOSS courses that spread the project’s development stage
over two semesters, either with the same group of students or with two different groups
of students. In one case, two different groups of students worked on the same project in
successive offerings of the same course. In another case, the same group of students worked
on the project over a unified 2-semester capstone “Software Projects” course. Both of these
approaches are viable when the institutional setting allows that flexibility.
7The recent rise of Web application hosting services, often called ‘‘platform as a
service" or PaaS, may reduce or eliminate the need for a professional developer to be
involved in the deployment stage. In this case, the instructor should be willing to maintain
the software after the project has been deployed.
Preface ■ xxxiii
in Part II should normally be taken in order, and each chapter’s own
Milestone should be completed before continuing to the next chapter.
Part III is written mainly for the instructor and the professional devel-
oper, providing guidance on deploying a new CO-FOSS product, sup-
porting it, and disseminating it to the larger open source community.
The last Milestone appears at the end of this chapter and its comple-
tion signals completion of the entire project.
The Table of Contents shows how the chapters are laid out in each of these
three Parts. Of course, the devil is in the details, so let’s get started!
Clientcentered Software Development The Cofoss Approach Tucker
Acknowledgments
The CO-FOSS approach to software development is people-intensive. I am
fortunate to have worked with many extraordinary people who have con-
tributed to the CO-FOSS projects described in this book. I gratefully
acknowledge:
The student developers at Bowdoin and Whitman Colleges, for their will-
ingness to make the connection between academic work and community service
by completing these projects successfully: Adrienne Beebe, Hartley Brody,
James Cook, Johnny Coster, Moustafa El Badry, Felix Emiliano, Connor
Hargus, Jerrick Hoang, Richardo Hopkins, Noah Jensen, Phuong Le, Alex
Lucyk, Dylan Martin, Ruben Martinez, Nolan McNair, Jackson Moniaga, Je-
sus Navarro, Luis Munguia Orta, Maxwell Palmer, David Phipps, David Quen-
noz, Oliver Radwan, Sam Roberts, Luis Rojas, Taylor Talmage, Xun Wang,
Nicholas Wetzel, Ivy Xing, and Judy Yang.
The non-profit clients, for providing real-world settings in which the
software could be developed, customized, and deployed: The Blue Mountain
Action Council of Washington (Kathy Covey and Jeff Mathias); Ronald Mc-
Donald House Charities of Maine (Gabrielle Booth, Robin Chibroski, Geor-
gia Doucette, Whitney Linscott, Ashley MacMillan, Alicia Milne, Gretchen
Noonan, Karla Prouty, and Raymond Ruby); Ronald McDonald House Char-
ities of Rhode Island (Susan Czekalski, Michelle LePage, and Joanna Pow-
ers); and Second Helpings of South Carolina (Bruce Algar, Lili Coleman, and
Jon Peluso).
The professional developers, for supporting the software on the clients’
servers: Artopa LLC (David Tripp), Coursevector LLC, The Non-Profit
FOSS Institute, Pragmatics, Inc. (Dr. Long Nguyen), and Vivio Technologies,
Inc.
My faculty colleagues, for helping me understand the challenges of
teaching FOSS development as an academic and humanitarian enterprise:
Jim Bowring, Grant Braught, Janet Davis, Greg Hislop, Steve Huss-
Lederman, Bonnie MacKellar, Craig McEwen, Ralph Morelli, and Mihaela
Sabin.
The reviewers of this manuscript, for providing a wealth of conceptual and
detailed suggestions for improving it: Jim Bowring, Janet Davis, and Steve
Huss-Lederman.
xxxv
xxxvi ■ Acknowledgments
Dr. Jennifer Tucker, for helping me develop the idea of the Non-Profit
FOSS Institute, and then serving as its first Executive Director. And finally
my wife, Meg, for her lifelong commitment to education and humanitarian
volunteerism, and especially for introducing me to the first CO-FOSS client
at the Ronald McDonald House in Portland, ME in 2007.
Allen B. Tucker, February 2019
About the Author
Allen B. Tucker is the Anne T. and Robert M. Bass Professor Emeritus in
the Department of Computer Science at Bowdoin College. He held similar po-
sitions at Colgate and Georgetown Universities. He is currently a professional
software developer and President of the Non-Profit FOSS Institute (NPFI),
a 501(c)(3) organization that supports the development of free open source
software for non-profits by students and professionals.
Allen earned a BA in mathematics from Wesleyan University and an MS
and PhD in computer science from Northwestern University. He is the author
or coauthor of several books and articles in the areas of programming lan-
guages, software design, natural language processing, and computer science
education. He co-authored the 1986 Liberal Arts Model Curriculum in Com-
puter Science, served as Editor-in-Chief of the Handbook of Computer Science,
and co-authored the textbooks Programming Languages and Software Devel-
opment. He also served as Fulbright Lecturer at the Ternopil Academy of
National Economy in Ukraine, a visiting Erskine Lecturer at the University
of Canterbury in New Zealand, a Visiting Lecturer at ESIGELEC in France,
and a Visiting Professor at Whitman College.
Allen has been a member of NSF’s CISE Advisory Board, the Association
for Computing Machinery (ACM), the IEEE Computer Society, Computer
Professionals for Social Responsibility, and the Liberal Arts Computer Science
(LACS) Consortium. In 1991, he received the ACM Outstanding Contribution
Award and shared the IEEE Meritorious Service Award. He is also a Fellow
of the ACM and a recipient of the ACM SIGCSE Award for Outstanding
Contributions to Computer Science Education.
From 2008 to 2012, Allen served on the Advisory Board for the NSF
CPATH grant that supported Trinity, Wesleyan, and Connecticut College’s
Humanitarian Free and Open Source Software (HFOSS) initiative. That ex-
perience inspired him to begin engaging his own Bowdoin students in HFOSS
and developing a curricular model called CO-FOSS (client-oriented FOSS)
with his colleague Ralph Morelli at Trinity College.
From 2008 to 2015, he taught several software-development courses at
Bowdoin and Whitman Colleges using the CO-FOSS model with different
student teams. As a byproduct of this work, he developed strong working
relationships with non-profits such as the Ronald McDonald Houses in Maine
and Rhode Island, and food distribution organizations in South Carolina and
Washington.
xxxvii
xxxviii ■ About the Author
In 2013, with the belief that the CO-FOSS model would be viable in a large
number of undergraduate settings, Allen co-founded NPFI. NPFI’s mission is
to spread the development and deployment of open source CO-FOSS products,
teaching methods, grants, and other resources to other computing faculty, so
that they can engage their own students with real-world HFOSS development
for many more non-profit organizations in the future.
C H A P T E R 1
The Journey
“Change your opinions, keep your principles;
Change your leaves, keep intact your roots.”
—Victor Hugo
This chapter provides an overview of software — its nature, its development
models, its licensing alternatives, its architectures, and its maturity. Thus
it offers a useful perspective within which the development of a new software
product can be viewed.
CO-FOSS is a model for developing new software. It is a particularly valu-
able model, both for learning about the software process and for developing
an actual software product for a real client. To provide a broader context,
Section 1.2 discusses three different software development models: the serial
model, the agile model, and the CO-FOSS model.
Fundamental to CO-FOSS development is the free and open source li-
cense that accompanies the software itself. Without such freedom, CO-FOSS
development would not be possible. This idea is discussed more carefully in
Section 1.3.
A key characteristic of any software product is its underlying architecture,
or organization. A coherent architecture is always an essential component of
all but the most simple software products. Section 1.4 introduces the client-
server family of software architectures that underly the organization of many
CO-FOSS products.
Different software products also vary in their maturity. The idea of CO-
FOSS applies mainly to the development of new software, often from pre-
existing components. However, most software is more mature, having evolved
through various levels of maturity over its lifespan. Section 1.5 looks at this
larger temporal context in which CO-FOSS development lies.
1.1 SOFTWARE
Simplistically, “software” can be viewed as all the programming in a computer
that is not hardware. But the very idea of “software” is a complex one. Even
1
2 ■ Client-Centered Software Development: The CO-FOSS Approach
the software on a single computer exists at two distinct levels – the operating
system/network level (think Linux, Windows, MacOS, or Apache Server) and
the application level (think Microsoft Office, OpenOffice, the Chrome browser,
or the Google Maps application).
Professional software developers have skills that reflect the level and type
of software that they develop. For example, Linux and network software de-
velopers work at the operating system/network level. Their skills allow them
to work with such tools and techniques as C programming and process syn-
chronization.
Other professional software developers work at the application level, such
as Web programming or database design, which requires a different set of
skills. The application level alone spans a wide range of distinct areas, each
of which has its own community of developers. Here’s just one taxonomy of
software application areas that appears in Wikipedia:
Information systems software supports corporate payroll, account-
ing, and inventory management, and individual word processing, spread-
sheet, and visual presentation needs.
Entertainment software includes video games, mobile games, and
social networks.
Educational software includes course management, survey manage-
ment, and language learning support.
Enterprise infrastructure software includes project management,
database systems, document management, and content managed web-
sites.
Simulation software simulates social networks, battlefield scenarios,
airline flight control, and vehicle driving control.
Media development software includes computer graphics and ani-
mation, graphic art, image galleries, audio and video editing, and digital
music generation.
Product engineering software includes compilers, interpreters, vir-
tual machines, computer aided design tools, integrated development en-
vironments (IDEs), version control systems (VCS), and debuggers.
How big is the software industry? The number of professionals in this
industry is large and growing. A recent study estimated that there were
21 million software developers worldwide in 2016. Of those, nearly 4 mil-
lion worked in the United States, and they comprised 2.5% of the total US
workforce. At the same time, demand for software professionals greatly
exceeds supply, creating a favorable job market for new developers who are
completing computer science, IT, and computer engineering degree programs.
The Journey ■ 3
1.2 SOFTWARE DEVELOPMENT MODELS
Software is also complex in the sense that a software product can be developed
using different methodologies, or “development models.” On the one hand, it
can be developed serially, starting from a fixed set of requirements, proceeding
to a design specification, followed by writing the code and finally testing the
code. On the other hand, it can be developed from the “bottom up,” start-
ing with a small prototype and incrementally adding new requirements and
functionality with each iteration.
Additionally, some software can be developed as a generic product for a
large (real or imagined) market, while other software can be developed as
a customized product for a single client. The former approach is potentially
more profitable, while the latter approach is useful for an organization that
has unique software needs that are unmet by commercially-available software.
Finally, software can be developed from scratch (sometimes called a “green-
field” project), or it can be developed incrementally using pieces of code bor-
rowed from other software with similar features (a “brownfield project”).
This section briefly addresses three different software development models,
their constraints, and their tradeoffs.
1.2.1 Serial Development
The serial approach to developing software originated as the so-called “wa-
terfall model,” and it was the predominant approach to developing software
throughout the 1970s and 1980s. It is based on the assumption that a software
product’s functional requirements can be fully specified at the outset, and that
subsequent stages in the development process can be carried out more-or-less
serially. These stages are called “requirements analysis,” “design,” “coding,”
“testing,” and “delivery.”
Each stage in this process is viewed as a single discrete event. One stage
typically does not begin until the previous stage is completed. Typically, the
client is involved in the beginning and ending stages, but not in the crucial
middle stages. This is illustrated in Figure 1.1.
If the requirements can be fully specified at the outset, the serial model can
work. For example, an embedded software module that measures and reports
the altitude of an airplane in real time can be designed and implemented using
this model.
However, this serial approach to software development has had a poor
record of success in completing software products for customers. For example,
the 2015 Chaos Report [19] surveyed 50,000 software projects around the
world to learn how well they met the following three criteria:
1. completed on time,
2. completed on budget, and
3. completed with all features implemented.
4 ■ Client-Centered Software Development: The CO-FOSS Approach
FIGURE 1.1 The serial (waterfall) software development model.
The Chaos Report found that only 11% of all projects using the traditional
serial model met all three criteria, while 60% were “challenged” (that is, they
were completed but did not meet all three criteria), and the remaining 29%
failed (that is, they were never completed).
So in many situations, the serial development model does not work well. Its
main problem lies in the assumption that the requirements of a software prod-
uct can be fully specified at the outset, and that those requirements will not
vary throughout the development process. In reality, various outside factors
(such as changing user needs or the emergence of a new computing platform)
can alter the requirements. For example, the 2015 Chaos Report [19] confirmed
that not incorporating end users’ feedback throughout the development pro-
cess was a frequent cause for software project failure.
1.2.2 Agile Development
Since the 1990s, and in response to these problems, software development
methodologies have been gradually evolving away from the serial model. Newer
methodologies known as “rapid application development,” “dynamic systems
development,” “scrum,” “extreme programming,” and “feature-driven devel-
opment” have been shown to be more effective in settings where changing
user requirements or computing platforms had become the norm. These newer
methodologies all led to the 2001 publication of the Manifesto for Agile Soft-
ware Development [5], which crystallized them into a coherent statement of
principles and a development model.
In recent years, the agile model and its variants have yielded significant
improvements over the traditional serial model. For example, the same 2015
Chaos Report [19] found that 39% of all projects that used the agile model
met all three of the above criteria for success, while 52% were challenged and
only 9% failed.
The main reasons for its improved success rate are explained by the nature
of the agile process itself. In an agile project, the software product starts with
The Journey ■ 5
a minimal set of requirements and iterates several times through a 6-stage
development cycle, as pictured in Figure 1.2. The process is fluid, in the sense
that each cycle improves the requirements and develops new code in response
to client feedback from reviewing the results of the previous cycle.
FIGURE 1.2 An agile software development cycle.
Let’s look at some of the details in the agile cycle. In stage 1, the developers
Meet with the client and discuss the client Review of the partially-completed
software from stage 6 of the previous cycle. In stage 2, the developers and client
assume new Tasks for making progress by adding new functionality and in-
corporating the client’s feedback from stage 1. Developers then independently
complete their respective Design, Code, and Test stages, thus preparing the
next version of the partially-completed software for client Review.
1.2.3 CO-FOSS Development
The CO-FOSS model for developing software is a hybrid of the serial and agile
models for software development. It borrows pieces from both, as summarized
in Figure 1.3.
To enable students to develop a useful piece of software for a single client
in one semester, the software Design is organized by the instructor and the
client before the semester begins, which is reminiscent of the serial model.
This activity is described in detail in Chapters 2 and 3.
Then the software Development is completed by students and the client
through a series of meet-task-code-test-review cycles. Each 1-2-week cycle is
repeated 5 or 6 times throughout the semester, each repetition achieving a
pre-determined milestone that ensures successful project completion.
6 ■ Client-Centered Software Development: The CO-FOSS Approach
FIGURE 1.3 The CO-FOSS software development model.
The Code stage relies on the fact that developers work with free and open
source software (FOSS). In the FOSS world, mature well-tested code can be
freely downloaded for reuse in any application with a similar functional need.
Thus, developers need to read and work with code written by others. Real
software is less often developed from scratch by a single individual. Instead,
it is usually developed incrementally by a team, each member adding and
refining parts of an existing “code base” written by others.
The Test stage in each iteration of the cycle provides a new opportunity
for debugging and refactoring the code base in preparation for client Review
and the next iteration.
Debugging means finding and correcting errors in the program. Bugs, or
instances of incorrect behavior, result from programming errors. Such
errors can often be notoriously difficult to find and correct, even when
working with a small code base. So as an aid to finding bugs we use an
aggressive strategy called “unit testing,” where individual units (classes
and modules) of code are individually tested at each repetition of a
CO-FOSS cycle.
Refactoring a program means reading the code, finding instances of poor
programming practice (from either a readability or an efficiency stand-
point), and reorganizing the code so that it performs the same functions
in a more readable and/or efficient way.
Coding, testing, debugging, and refactoring are discussed in detail in Chapters
5, 6, and 7.
Clients further test and evaluate the software during the Review stage of
each cycle. They play a key part in debugging, since they are the ones who
most often identify bugs and provide feedback to developers during each cycle,
ensuring that the final product meets their particular expectations. A more
The Journey ■ 7
careful treatment of the client review process and its close relationship to the
Test stage appears in Chapters 5, 6, and 7.
Finally, Deployment of the CO-FOSS product takes place at the end
of the semester, and is coordinated between the instructor, the client, and a
professional software developer. This is described in detail in Chapter 9.
1.2.4 Software Customization: A Continuum
A final consideration for software developers and clients involves the alter-
natives that are available in selecting/developing a software product to help
improve a particular mission-critical activity within the organization. These
choices form a continuum – from developing a completely customized soft-
ware product to obtaining a completely off-the-shelf product, with many other
choices in between. Let’s take a look at the trade-offs among three key choices
in this continuum:
Custom software,
Off-the-shelf software, and
Custom software with off-the-shelf components.
Custom Software
Custom software is just what its name suggests. The developer designs and im-
plements a unique piece of software that can improve a client’s mission-critical
activity. The software is tailored to match all that activity’s needs, processes,
and security requirements. Importantly, the client’s staff can assimilate that
software easily because it uses existing organizational vernacular that the staff
already knows.
Custom software may be open source or proprietary (see Section 1.3), but
the client must rely on the developer to keep it up to date with changing
organizational needs. So a strong working relationship between the developer
and client is essential for custom software to remain effective. Custom open
source software is ideally client-centered, allowing the client to be involved
continuously in the development process.
Custom software is not without its downsides. First, its original develop-
ment cost can be higher than the alternatives, if there are any. Second, asking
the developer to add new features as requirements change may also be bill-
able. Third, custom software has no peer user community outside the client’s
organization to provide advice on usability issues, though this downside is
somewhat mitigated by the developer’s ongoing availability.
All the software projects discussed in this book have developed custom
open source products. Each one is fitted to satisfy the requirements of a sin-
gle customer. For example, Homebase was originally developed in 2008 for the
Ronald McDonald House in Portland, ME. Enhancements were made by differ-
ent student teams in 2012 and 2013. A single developer returned in 2015 to add
8 ■ Client-Centered Software Development: The CO-FOSS Approach
more features to Homebase. These results would not have occurred if Home-
base were not open source and developed using a client-centered approach.
When weighing whether to use custom software, an organization should
be sure that there is no satisfactory off-the-shelf product available that can
satisfy its requirements at an affordable cost. It should also find a developer
that can produce that custom software and provide ongoing support, all at an
affordable cost. For example, all the software products discussed in this book
were developed and are supported at no cost to their clients. However, since
each of these products was developed using the CO-FOSS model, it did require
client participation (averaging about 2 person-hours per week) throughout its
development process.
Off-the-Shelf Software
Off-the-shelf software is a (proprietary or open source) product developed
for a large number of customers. Examples include Microsoft Word, Apache
OpenOffice, Google Sheets, and various smartphone- and tablet-based com-
puter games. Off-the-shelf software is aimed at addressing a specific shared
need of a mass market audience, such as the need to play a game of Sudoku
on a smartphone while waiting for an airplane.
The per-user cost of off-the-shelf software can vary greatly; some products
are free, others are costly, and still others are available as both free “intro-
ductory” versions and paid “full” versions. The full versions of off-the-shelf
software usually come with a preponderance of features, most of which are not
needed by the average user. These features are there in order to satisfy the
one-size-fits-all requirement. However, their presence can make the software
more difficult to learn and use.
Off-the-shelf software can be deployed quickly, usually with a simple down-
load and install step. Another advantage of popular off-the-shelf software
products is that they have large, often international, communities of users
and forums that provide self-help support. So the user doesn’t need to hire a
developer to fix a bug or customize the software to fulfill a specific need.
On the downside, off-the-shelf software typically will not match all of an
organization’s needs, either lacking needed features or providing superfluous
features. If customization is even possible, that typically comes at an addi-
tional cost. Routine upgrades may also come with additional costs.
Finally, off-the-shelf software can be obsolete or slow to evolve with the
industry to which it is targeted. Moreover, its vernacular is invariably out of
sync with the user organization’s vernacular, requiring users to assimilate a
new vocabulary before becoming comfortable with the software. Off-the-shelf
software may also require technologies that do not conform to the organiza-
tion’s current computing platform. Moreover, it often comes with the subtle
inability for an organization to change to a different vendor in the future when
a better alternative emerges (this is sometimes called “vendor lock-in”).
The Journey ■ 9
Custom Software with Off-the-Shelf Components
There is a middle ground between custom software and off-the-shelf software,
which is becoming an increasingly popular solution for organizations. The
idea of “custom software with off-the-shelf components” is that an organiza-
tion finds software that matches most of its specific needs but requires a few
additional functions in order to match the rest. Typically, this approach uses
open source software at its core, though some of the add-on components can
be proprietary as well.
A good example is Wordpress, which is free open source software out of the
box for building websites. A Wordpress website can be customized by adding
“plugins” which are modules that provide specialized functionality so that the
website can provide specific functionality that matches an organization’s pe-
culiar requirements. The Wordpress plugin library is huge, and it covers a wide
range of functionalities, such as membership management, on-line application
form processing, and on-line product catalogs for e-commerce.
The advantages of this approach to software development are mainly that
it leverages pre-existing libraries of reliable modules to help reduce up-front
costs, especially those associated with writing and testing new code. Other
advantages are derived from its basic open source nature: the organization
owns the software and its attendant database (avoiding vendor lock-in), the
software can be continuously updated to meet changing needs, and there are
no licensing fees.
The disadvantages of this approach are higher upfront costs vs. off-the-shelf
software and the requirement for an ongoing relationship with a developer to
make changes and upgrades (which may be billable). Like custom software,
this approach has no attendant user community to provide self-help (though
the relationship with the developer compensates for this).
1.3 SOFTWARE LICENSING
A software product can be licensed in one of two general ways, proprietary or
open source. The differences between these two types of licenses are significant,
especially in regard to the software development process and environment in
which the software is created and maintained.
1.3.1 Proprietary Licensing
Proprietary software is that which is licensed and sold as a binary executable
program to individual and corporate customers. The source code is the private
property of the developer and is kept hidden from the customer. A proprietary
software license typically limits the number of computers on which a user
can install the software – installing the software on more than one computer
costs more money. So a proprietary license prevents the user from copying the
software, modifying it, or sharing it freely with associates and friends.
10 ■ Client-Centered Software Development: The CO-FOSS Approach
From the 1970s to the mid-1980s, nearly all software was developed and
sold with a proprietary license. Proprietary software is developed and main-
tained by an in-house programming staff of a large organization or by a vendor
targeting a specific market. All developers of a proprietary software product
must sign a non-disclosure agreement (known informally as an NDA) which
binds them to secrecy about the product’s source code and architecture.
For example, Word was developed by Microsoft’s own programmers to
meet the needs of the word processing market. Today it can be bought by
a single user either stand-alone (for $110) or as part of Microsoft’s “Office
365” bundle, a cloud-based subscription service that includes Word, Excel,
PowerPoint, OneNote, Outlook, Publisher, Access, OneDrive, and Skype (for
a $70 yearly subscription). The license for a single-user version of Word is a
30-page document “Microsoft Software License Terms,” which spells out that
the user has the right to install and use a single copy of the software on a single
computer, but cannot copy it to a second computer or pass it to a friend.
Google Docs is a proprietary word processor that runs on a web server and
is a free alternative to Microsoft Word. While Google Docs is less feature-rich
than Word, many users prefer that because of its intuitive functionality and
its interoperability with other aspects of cloud computing. Most importantly,
Google Docs’ cloud-based functionality supports smooth simultaneous editing
of a shared document by several persons. Microsoft’s cloud-based version of
Word, when it is bundled within Office 365, also supports this kind of collab-
oration.
1.3.2 Open Source Licensing
Free and open source software (FOSS) is software whose source code and
binary executable code are freely available for download by any individual
or organization. Most significantly, “freely” means that downloaders are free
to use the software on any computer, to modify the source code and binary,
and to share the modified software with associates and friends. Because of
this freedom, FOSS is accessible in markets where proprietary software has
no interest and little leverage—non-profit organizations, developing countries,
and individuals and businesses who are either unwilling or unable to pay the
cost of purchasing proprietary software.
Most proprietary software has a FOSS alternative. For example, a FOSS
alternative to Microsoft Word is called “Writer” and is part of the “OpenOf-
fice” bundle, maintained and distributed by the Apache Foundation. OpenOf-
fice allows any individual or organization to freely download and use it on any
number of computers. It runs on Windows, Linux, and Macintosh platforms.
OpenOffice is distributed under an open source license called the “Apache
License Version 2.0,” which describes the rights of clients to download and
freely use, copy, modify, and redistribute this software. The Android operat-
ing system also carries the Apache license [24].
The Journey ■ 11
Besides the Apache License, three slightly different types of licenses are
used for FOSS products:
The MIT License [27] was developed by the Open Source Initiative to
provide a totally unrestricted vehicle for reworking and redistributing
the source code.
The GNU General Public License [14], or GPL for short, was devel-
oped by the GNU Foundation to provide a vehicle for reworking and
redistributing the source code, but with the caveat that any redistribu-
tion must be GPL-licensed FOSS as well. This caveat effectively keeps
all derivatives of the product in the FOSS domain for other developers
to freely use and refine.
The Mozilla Public License, or MPL for short, was developed by the
Mozilla Foundation for its Firefox browser and is used by many other
software products today.
Many popular FOSS products (Linux and Wordpress, for example) are
licensed under the GPL, preventing them from ever being commercialized or
embedded inside a proprietary product. Version 2 of the GPL was released
in 1991. The GPL has been repeatedly upheld in courts around the world as
an enforceable license [2]. Since 1991, a variety of FOSS licenses have evolved
alongside the GPL to satisfy different needs within the open source commu-
nity. GPL version 3 (GPLv3) was released in 2007 to address a wide range of
issues, especially its compatibility with these other FOSS licenses.
Unlike the GPL, neither the Apache License nor the MIT license protects
a software product from having one of its derivative products converted into
a proprietary product and sold for profit. For example, Apple’s MacOS op-
erating system is proprietary software derived from the FOSS product BSD
Unix, which carries an MIT-like (permissive) license.
The LGPL and MPL represent a middle ground between the permissive
MIT license and the protective GPL license. That is, while they protect the
FOSS software and its derivatives from becoming fully proprietary, they allow
the software to be embedded in a larger proprietary product.
Today, there are dozens of different FOSS licenses. The Free Software Foun-
dation’s own list of other licenses cites rulings on which ones are compatible
with the GPL as well as guidance on how to define customized FOSS li-
censes [15]. The Open Source Institute maintains a similar list as part of its
effort to define open source software [27].
One of the most difficult questions for FOSS developers is how the vari-
ous licenses relate to each other. Figure 1.4 [44] provides an overview of the
more widely used licenses and their inter-relationships. Each box represents a
particular kind of license.
A license is more or less protective depending on how strongly it protects
the freedoms listed in the FOSS definition, particularly the freedom to re-
distribute derivatives of the software. The left-to-right arrangement of the
Other documents randomly have
different content
their fellow-servants, but were attacked by superior numbers of the
Canadians, and beaten off, with violence and bloodshed.
CHAPTER XXIX.
1808-1812.
Crisis in the Company's Affairs—No Dividend Paid—Petition to Lords
of the Treasury—Factors Allowed a Share in the Trade—Canada
Jurisdiction Act—The Killing of MacDonnell—Mowat's Ill-treatment
—Lord Selkirk—His Scheme laid before the Company—A Protest by
Thwaytes and others—The Project Carried—Emigrants sent out to
Red River—Northmen Stirred to Reprisal.
England was again at war with France. Napoleon had placed an
embargo on English commerce, and to the uttermost corner of
Europe was this measure felt. Tons of the most costly furs, for which
there was no market, lay heaped in the Company's warehouse. The
greatest difficulty was experienced in procuring servants, especially
seamen, and when these were procured, they were often seized by
a press-gang; shares began to decline in value; numerous partners
were selling out their interests, and no strong man appeared at the
head of affairs.
In 1808 no dividend was paid, chiefly the result of the non-
exportation of the Company's furs to the Continent of Europe. There
were the accumulations of furs imported during 1806, 1807 and
1808 lying in the warehouse without prospect of sale.
The pressure still continued and at last, in 1809, the Company was
driven to petition the Chancellor of the Exchequer for transmission to
The Company in
difficulties.
Lords of the Treasury, setting forth the Company's position and its
claims on the nation.
"Accumulated difficulties," it said, "have pressed
hardly on the Company and we ask assistance to
maintain a colony that till now has found within
itself resources to withstand the pressure of all former wars and to
continue those outfits on which six hundred Europeans and their
families and some thousands of native Indians depend for their very
existence.
"We assure your worships that it was not until all those resources
were exhausted that we came to the resolution of making the
present application."
The petition recited that after having received their charter the
Company had colonized such parts of newly granted territories as
appeared most convenient for carrying on their commerce with the
natives. This commerce "consisted in the barter of British
manufactures for the furs of animals killed by the different tribes of
Indians who were within reach of factories and gradually extended
itself till, as at the present moment, the manufactures of Great
Britain are borne by the traders of Hudson's Bay over the face of the
whole country from Lake Superior to the Athabasca.
"The trade is at present pursued by the export of furs, gunpowder,
shot, woollens, hardware and other articles, which together with
large supplies of provisions for the factories, constitute an annual
outfit consisting wholly of British manufactures and British produce
of from £40,000 to £50,000, in return for which we receive the furs
of bears, wolves, foxes, otters, martens, beaver and other animals,
together with some oil and articles of inferior value. The cargoes are
sold at public sale. The beaver and some few inferior furs, together
with the oil, are bought for home consumption and sell for about
£30,000, but the fine furs were, till after the sale of 1806, bought by
the fur merchants for the fairs of Frankfort and of Leipsic for
Petersburg, and before the present war, for France. Since that year
there has not been a fur sold for exportation, and as a proof to your
worships that the deficiency of buyers did not arise from our holding
back for a higher market, we sold in 1806 for seven shillings per skin
furs that in the more quiet state of Europe in 1804 had brought us
20s. 3d., and which for years previous to that time had sold for a
similar price; and other depreciation pervaded in about the same
proportion the whole of those furs calculated only for the foreign
market, and in some instances furs were sold for a less price than
the duties we had paid for them.
"Since that period no orders have been received from abroad, and
our warehouses are filled with the most valuable productions of
three years' import that if sold at the prices of those years before
the closing of the ports on the Continent would have produced us at
least £150,000.
"It may be objected to us, that we were improvident in pursuing
under such circumstances a trade which must so inevitably tend to
ruin. But a certainty that a considerable quantity of furs found their
way to New York, and an earnest zeal for the preservation of trade
which by the conduct of the Hudson's Bay Company had been
secured to this country for a century and a half, prompted us to
every exertion to maintain the footing we had established, and the
annually increasing amount of our trade gave us just grounds to look
forward with confidence to the opening of the northern ports of
Europe as the period when all our difficulties would cease; an event
which, anterior to the battles of Austerlitz or of Jena, was looked for
with the most sanguine expectation.
"Above all were we impelled by the strongest motives to continue
these supplies which were necessary for the subsistence of six
hundred European servants, their wives and children, dispersed over
a vast and extended field of the North American Continent, and who
would not be brought to Europe under a period of three years as
well as those upon whom the many Indian nations now depend for
their very existence.
Petition of the
Company.
"The nations of hunters taught for one hundred and fifty years the
use of fire-arms could no more resort, with certainty, to the bow or
the javelin for their daily subsistence. Accustomed to the hatchet of
Great Britain, they could ill adopt the rude sharpened stone to the
purposes of building, and until years of misery and of famine had
extirpated the present race, they could not recur to the simple arts
by which they supported themselves before the introduction of
British manufactures. As the outfits of the Hudson's Bay Company
consist principally of articles which long habit have taught them now
to consider of first necessity, if we withhold these outfits, we leave
them destitute of their only means of support. The truth of this
observation had a melancholy proof in the year 1782, when from the
attack made upon the settlements by La Pérouse, and the
consequent failure of our supplies, many of the Indians were found
starved to death.
"It was not only from the firm conviction that we
felt of the necessity of European manufactures to
the present existence of whole nations of North
American Indians that we considered ourselves bound by the most
powerful ties to exert every effort in their favour; but also that we
might continue to them those advantages which would result to their
religious as well as civil welfare from the progressive improvements,
and a gradual system of civilisation and education which we have
introduced throughout the country; improvements which are now
diffusing the comforts of civilized life, as well as the blessings of the
Christian faith to thousands of uninstructed Indians, and would in
their completion, we can confidently assert, have tended to the
future cultivation of lands, which from experiments we found
capable of growing most of the grains of Northern Europe, and from
their climate adapted to the culture of hemp and flax, and from the
labour of those families who would have been induced to settle at
our factories, might soon have brought to this country the produce
of the boundless forests of pine that spread themselves over almost
the southern parts of our possessions.
"To realize these not visionary schemes, but sure and certain plans,
founded upon the progressive civilization of the natives, were
objects not to be given up without the most urgent necessity, and
the hope that the ruler of the French Empire could not forever shut
out our trade from Europe, induced us to resort to every means
within our power to preserve the advantages resulting to ourselves
and to the Indians, and to the British nation.
"We have exhausted those funds which we set apart for their
completion; we have pledged our credit till we feel, as honest men,
that upon the present uncertainty we can pledge it no farther, and
we throw ourselves upon your Worship's wisdom to afford us that
temporary assistance which we cannot ask at any other hands.
"Were we to resort to the early history of our settlements, we might
lay the foundations of just claims upon the public to assist our
present wants. We could show instances of most destructive attacks
by the French upon our factories. Our forts and military works,
mounted with a numerous and expensive artillery for the defence of
the colony against their future operations, were destroyed and the
guns ruined. And particularly was a most grievous loss occasioned to
us by the predatory attack of La Pérouse about the conclusion of the
American War, which caused the distress to which we have above
alluded.
"Against these pressures when our trade flourished we were able to
hold up, and we found within ourselves those resources which
defeated the enemy's views and continued to Great Britain the trade
we had established.
"And it is not until pressed to our last resort that we ask of your
Lordships that assistance with which we may confidently hope to
preserve our trade until the continent may be again opened, when
we shall be delivered from those difficulties under which we are now
sinking."
Small Government
assistance.
The petition was signed by Wm. Mainwaring, Governor; Joseph
Berens, Deputy Governor; George Hyde Wollaston, Thomas Neave,
Job Mathew Raikes, Thomas Langley, John Henry Pelly, Benjamin
Harrison, John Webb.
In April the Adventurers petitioned the King in Council to reduce
duties on furs to one-half, or trade must suffer extinction. No profit
was derivable, it said, on marten, wolf, bear, wolverine and fisher-
skins.
To this petition the Office of Committee of Privy Council for Trade,
Whitehall, replied in the following February, that the memorial of the
Hudson's Bay Company contained no proposition on which the Lords
of this Council could "offer any opinion to the Lords of Treasury."
As their petition was denied, the Company now
boldly prepared a request and asked for a loan of
£60,000, and that time be extended for paying the
duties on furs imported until the continental market re-opened. To
this request an answer was returned, allowing twelve months
storage of furs free of duty and promising drawbacks as if storage
had only been for one year, but stating that there were no funds out
of which a loan could be made without special authority of
Parliament.
It was clear that the Company was in very low water, and that some
new salutary policy was demanded. By way of a beginning, barter
was abolished as a basis of trade, and money payments ordered. At
the same time the Adventurers stole a leaf out of the book of the
North-West company, and new regulations, comprising thirty-five
articles, were made in the early months of 1810, for carrying on the
business in Hudson's Bay.
The principle of allowing to their chief officers a considerable
participation in the profits of their trade was admitted. It was found
absolutely necessary to adopt some step of this sort, as nothing of
such a measure could be sufficient to stem the torrent of aggression
with which they had been assailed by the North-West company; and
their absolute ruin must have ensued if some effectual means had
not been taken, not only to rectify some of the abuses which had
crept in under the former system, but also to rouse their officers to a
more effectual resistance of the lawless violence practised against
them.
The total lack of jurisdiction in the Indian country, as the territory
which was the scene of the operations of the fur-traders was called,
permitted crime to go unpunished, and numerous representations
were made in respect to the evils of this practical immunity from
punishment. In Sir Alexander Mackenzie's letter of the 25th of
October, 1802, he says that, in view of the improbability of the two
companies amalgamating, a jurisdiction should be established as
speedily as possible, to prevent the contending fur companies from
abusing the power either might possess, so as to secure to each the
fruits of fair, honest and industrious exertion; it would also, he
believed, tend to put a stop to the increasing animosity between the
two companies. Mr. Richardson, of the other company, also pressed
for the establishment of a competent jurisdiction and instanced the
case of one of the clerks in his company who had killed a clerk of
the other in defending the property in his care. The young man had
come to Montreal to be tried, but there being no jurisdiction there
for such trial, "he remains in the deplorable predicament that neither
his innocence nor his guilt can be legally ascertained." He also
proposed that a military post should be established at Thunder Bay,
on Lake Superior, as an additional means of securing peace.
Repeatedly had the Grand Juries of Quebec and Montreal called
attention to this want of jurisdiction. In one report the number of
people from the Canadas, chiefly from Lower Canada, was urged as
one reason for establishing in the Indian country a court of
competent jurisdiction for the trial of offences committed in these
territories, including Hudson's Bay.
"The very heavy expense," observes the report, "incident to the
conveyance of offenders from the Territory of Hudson's Bay to
Plea for
establishment of
jurisdiction.
England, with the necessary witnesses on both
sides, and the cost of prosecution and defence,
must generally operate, either to prevent recourse
to a tribunal across the ocean, and thereby
stimulate to private retaliation and revenge, or where such course
can or shall be had, the guilty may escape punishment, and the
innocent be sacrificed from the distance of time and place of trial,
the death or absence of witnesses, or other causes; and the mind
cannot contemplate without horror the possible abuses to which
such circumstances might give rise; as in the instance of a
prosecutor coming from and at a remote day, when the accused may
be destitute of pecuniary means, and the exculpatory evidence may
either be dead, removed, or be otherwise beyond his reach, who at
all events (however innocent he may finally be found) will have
undergone a long and painful confinement, far removed from his
family and connections, and perhaps ruinous to every prospect he
had in life."
Sir Robert Milnes strongly supported the representation of the Grand
Jury, and added that "Under such circumstances every species of
offence is to be apprehended, from Trespasses to Murder," and also
that "the national character of the English will be debased among
the Indians, and the numerous tribes of those people will in
consequence thereof be more easily wrought upon by foreign
emissaries employed by the Enemies of Great Britain."[88]
In consequence of these representations Lord Hobart promised that
immediate steps should be taken to remedy the existing state of
affairs. But Milnes became impatient for a decision, and writing in
September, 1803, to the Under-Secretary, he reminded him of the
promise, the great increase and extent of the fur-trade rendering
such an Act daily more necessary. The Act to give jurisdiction to the
Courts of Upper and Lower Canada had, however, been assented to
on the 11th of the preceding month.
Canada Jurisdiction
Act.
Voyageurs Tracking Canoes up a Rapid.
The first case brought to trial under the Act
became celebrated. In the autumn of 1809 William
Corrigal was the trader at a Company's post near
Eagle Lake. On the 15th of September a party of North-Westers
established an encampment about forty yards from the Company's
post, under one of their clerks, Aeneas MacDonnell. In the evening
an Indian arrived in his canoe to trade with Corrigal and to pay a
debt which he owed him. As he was not able to defray the whole
amount, Corrigal accepted the canoe in part payment. The Indian
requested that it might be lent to him for a few days, which was
agreed to; and the Indian spent the night at the post with his canoe.
In the morning he received in advance some more merchandise,
such as clothing for his family and ammunition for his winter hunt.
When he finally departed, three of the Company's servants were
sent down to the wharf with the canoe and the goods. On their way
they were observed by a number of Northmen, including
MacDonnell, who went immediately down to the lake, armed with a
sword and accompanied by a voyageur named Adhemer, armed with
Killing of
MacDonnell.
a brace of pistols. Upon pretence that the unhappy Red man was
indebted to the North-West company, they proceeded to seize and
drag away the canoe and the merchandise to their own wharf.
Corrigal observing this, commanded two of his men, James Tate and
John Corrigal, to go into the water and prevent the seizure, and as
they approached on this mission MacDonnell drew his sword and
struck two blows at Tate's head. The latter was unarmed, and
warded the blows with his wrist, which was severely gashed. He
then received another deep wound in the neck, which felled him to
the ground. In the meantime Adhemer had seized John Corrigal
(who was also unarmed) and presenting a cocked pistol at his head,
swore that if he went near the canoe he would blow out his brains.
Several of the Company's servants who were near the spot,
perceiving what was going on, and observing that the rest of
MacDonnell's men were collecting with arms, ran up to their own
house, which was only about forty or fifty yards from the lake, for
weapons of defence. MacDonnell next attacked John Corrigal, who
to escape him ran into the lake. Finding the water too deep,
however, he was soon obliged to make a turn towards the shore. His
pursuer wading after him, aimed a blow at him with his sword, cut
his arm above the elbow and laid the bone bare. He followed this up
with a tremendous blow at his head, which Robert Leask, one of the
Company's servants, fortunately warded off with the paddle of his
canoe, which was cut in two by the blow. The North-West leader in a
fury now attacked another servant named Essen, aimed a blow at
him with his sword, which, however, only struck his hat off. But in
making his escape Essen fell into the water. Before he could recover
himself another Canadian aimed a blow at his head with a heavy
axe, which missed its aim, but dislocated his shoulder, so that he
could make no use of his arm for over two months after this affray.
MacDonnell and Adhemer, the one with a drawn
sword and the other with a cocked pistol,
continued to pursue several other of the
Company's servants towards the fort, when one of them, named
Trial of Mowat.
John Mowat, whom MacDonnell had previously struck with his
sword, and was preparing to strike again, shot MacDonnell on the
spot.
MacDonnell's body was carried away, and the
parties separated, Corrigal fearing a further attack.
On the 24th, a partner of the North-West
Company, named Haldane, arrived in a canoe with ten men, and on
the following day another partner, McLellan, also arrived. They came
to the gates of the stockades, behind which Corrigal and his men
had barricaded themselves, and demanded the man who had shot
MacDonnell. They declared that if the person was not immediately
given up they would either shoot every one of the Company's men,
or get the Indians to kill them, were it even to cost them a keg of
brandy for each of their heads! Mowat now stepped forward and
acknowledged that he was the man, and that he would shoot
MacDonnell again in the same circumstances. Much to his surprise
the North-Westers announced their intention of taking him and two
witnesses down to Montreal for trial. Mowat was thereupon put in
irons. From the 2nd of October, when they arrived at Rainy Lake, the
unhappy man was generally kept in irons from six in the morning till
eight in the evening, and during the night until the 14th of
December. During the whole winter he was kept in close
confinement, and the two witnesses, Tate and Leask, who had
voluntarily accompanied him, were themselves subjected to much
insult and indignity, and were obliged to submit to every species of
drudgery and labour in order to obtain a bare subsistence. In June
the whole party, including Corrigal, arrived at Fort William, the chief
trading-post rendezvous of the North-Westers. Here Mowat was
imprisoned in a close and miserable dungeon, about six feet square,
without any window or light of any kind whatsoever, and when he
finally reached Montreal he was in a most pitiable condition. The
witnesses were seized on a charge of aiding and abetting the murder
of MacDonnell, and this upon the oath of one of the North-West half-
breeds. The Hudson's Bay Company had at this time no agent or
correspondent at Montreal or any place in Canada, and it was not
The Earl of Selkirk.
until the end of November that the Honourable Adventurers heard of
the prosecution being carried on against their servants. Immediate
steps were taken for their protection, and counsel engaged for the
defence. Mowat and his witnesses were indicted for murder. The
grand jury found a true bill against Mowat, but not against the
others, and Tate and Leask were accordingly discharged.[89]
In spite of the evidence, the jury brought in a verdict of
manslaughter. The judge, however, had charged them to find it
murder. Mowat was sentenced to be imprisoned six months and
branded on the hand with a hot iron. After his discharge, two years
from the time he was first put in irons at Eagle Lake, Mowat
proceeded from Canada to the United States in order to return to
England, but was never heard of again. He is supposed to have been
drowned by the breaking of the ice in one of the rivers he had to
cross on his way.
Such was the situation in the early years of the
century. At this time there rose a name destined
to be of more than local fame, that of Thomas
Douglas, fifth Earl of Selkirk, a young man of benevolent character,
whose feelings had been deeply moved by the sufferings of his
countrymen in the Scottish Highlands. Nor was the nobleman's
compassion excited without cause. A compulsory exodus of the
inhabitants of the mountainous regions in the county of Sutherland
was in progress. The tale of expulsion of a vast number of poor
tenantry from the estates of the Duchess of Sutherland, which they
and their ancestors had looked upon as their own without the
necessity of rent and taxes, may be heard to-day from some white-
haired old grandfather, who had it from the lips of his sire, in the far
north of Scotland. The system of rents and land-management as it
prevails to-day all over the Highlands had only then been put in
force, and the squatters were driven to seek their homes as best
they might in the remote and sequestered places of the earth.
Selkirk encouraged this emigration as the only remedy; and having
endeavoured in vain to secure the active co-operation of the
Government, resolved to settle a colony on waste lands granted him
in Prince Edward Island. The better to ensure success, he went in
person to oversee the whole enterprise. Gathering together about
eight hundred of these poor people, who bade a melancholy farewell
to their heather-robed hills, they arrived at their future home early in
September, 1803.
Lord Selkirk.
Selkirk visited Montreal in this and also in the following year on
matters connected with his philanthropic undertaking, and on both
occasions evinced the heartiest interest in the great territory to the
north-west which formed the theatre of action for the two rival fur-
trading companies.
The Prince Edward Island colony continuing to prosper, Lord Selkirk
now conceived the plan of forming a colony on the banks of the Red
River, in Rupert's Land.[90] In order to execute his project with a
greater assurance of success, he again, in 1805, addressed the
Legal opinion on the
Company's charter.
British Government and nation, pointing out the successful issue of
his colony as an example of the excellent results which would attend
a further exodus of the superfluous population.
Time went on and the execution of the plan being still in abeyance,
the great decline in Hudson's Bay stock suggested an idea to Selkirk.
He submitted the charter to several of the highest legal authorities in
England, and got from them the following:
"We are of the opinion that the grant of the said contained charter is
good, and that it will include all the country, the waters of which run
into Hudson's Bay, as ascertained by geographical observations.
"We are of opinion that an individual holding from
the Hudson's Bay Company a lease or grant in fee
simple of any part of their territory, will be entitled
to all the ordinary rights of landed property in England, and will be
entitled to prevent other persons from occupying any part of the
lands; from cutting down timber and fishing in the adjoining waters
(being such as a private right of fishing may subsist in), and may (if
he can peaceably or otherwise in due course of law) dispossess
them of any buildings which they have recently erected within the
limits of their property.
"We are of opinion that the grant of the civil and criminal jurisdiction
is valid, though it is not granted to the Company, but to the
Governor and Council at their respective establishments. We cannot
recommend, however, it to be exercised so as to affect the lives or
limbs of criminals. It is to be exercised by the Governor and Council
as judges, who are to proceed according to the laws of England.
"The Company may appoint a sheriff to execute judgments and do
his duty as in England.
"We are of opinion that the sheriff, in case of resistance to his
authority, may collect the population to his assistance, and put arms
into the hands of his servants for defence against attack, and to
assist in enforcing the judgments of the courts; but such powers
cannot be exercised with too much circumspection.
"We are of opinion that all persons will be subject to the jurisdiction
of the court, who reside or are found within the territories over
which it extends.
"We do not think the Canada Jurisdiction Act (43 George III.) gives
jurisdiction within the territories of the Hudson's Bay Company, the
same being within the jurisdiction of their own governors and
council.[91]
"We are of opinion that the Governor (in Hudson's) might under the
authority of the Company, appoint constables and other officers for
the preservation of the peace and that the officers so appointed
would have the same duties and privileges as the same officers in
England, so far as these duties and privileges may be applicable to
their situation in the territories of the Company." This was signed by
Sir Samuel Ronully, Mr. Justice Holroyd, W. M. Cruise, J. Scarlett and
John Bell. There could be thus no question of Selkirk's right. The
Company's charter, amongst other provisions, expressly forbids all
English subjects from entering, without license or authority, upon the
territories of the Hudson's Bay Company. The Governor and
Company only are empowered to grant such authority and on them
also is conferred the right of establishing castles, fortifications, forts,
garrisons, colonies, plantations, towns and villages, in any parts or
places within the limits of their territory. They had also the right of
sending ships of war, men or ammunition, to their colonies,
fortifications or plantations, and of appointing governors,
commanders and officers over them.
Selkirk began by purchasing several thousand pounds worth of
shares in the Company.
Late in 1810 he made a formal proposition to the Company, a
proposition previously made and rejected, for a settlement to be
made within its territory. This time some of the Honourable
Selkirk's project.
Adventurers began to see that the scheme might be fraught with
salvation for themselves.
Lord Selkirk was asked to lay before the committee the terms on
which he would accept a grant of land within the Hudson's Bay
territories, "specifying what restrictions he would be prepared to
consent to be imposed on the settlers." Also what security he would
offer to the Company against any injury to its trade or to its rights
and privileges.
Lord Selkirk responded to this, and his proposals were agreed to,
subject to final approbation of a general court of all the Adventurers.
It now dawned upon the wiser spirits that here
was being offered them the means for the
Company's salvation. Nevertheless, the traditional
opposition of the Company to any project of the kind still lingered,
and was not easily disposed of. For weeks the meetings in
committee resounded with appeals to "traditional policy," to "loyalty
to the noble, the ancient founders," to "a spirit of reverence for the
history of our Company," but all to no purpose. Selkirk was to carry
the day. A general court was convened, by public notice, in May
1811, when the stockholders were informed that the Governor and
Committee considered it beneficial to their general interests to grant
Lord Selkirk 116,000 square miles of their territory, on condition that
he should establish a colony and furnish, on certain terms, from
amongst the settlers, such labourers as would be required by the
Company in their trade.
In order to give the partners a further opportunity of making
themselves fully informed of the nature of the proposed measure, an
adjournment of the court took place. In the meanwhile notice was
given to all the stockholders that the terms of the proposed grant
were left at the secretary's office for their inspection.
This interval was the opportunity of McGillivray and his friends.
Opposition by
agents of the North-
West Company.
In certain quarters, no pains or misrepresentations were spared by
persons associated with the North-West Company to prejudice the
public mind against it. The newspapers teemed with falsehoods
representing the country as cold or barren, as a dreary waste or
interminable forest, unfit to be the abode of men and incapable of
improvement. Selkirk was accosted in Pall Mall by a friend who
remarked: "By God, sir, if you are bent on doing something futile,
why do you not sow tares at home in order to reap wheat, or plough
the desert of Sahara, which is nearer."
Old servants of the Company came forward to dispel these
calumnies, and seeing their first falsehoods destroyed, Selkirk's
enemies now proceeded to follow new tactics. They spoke with
feigned alarm concerning the hostile disposition of the aborigines;
they lamented with affected sympathy and humanity the injuries and
slaughters to which the colonists would be exposed from the
savages.
At the adjourned meeting the proposition was again discussed
amidst the greatest excitement and tumult, and adopted. A
memorial or protest was however entered against the measure,
bearing the signature of six of the proprietors.
Of these six signing the protest, three were
persons closely connected with and interested in
the rival commercial concerns of the North-West
Company of Montreal; and two of the three were,
at the very moment, avowed London agents of that association.
These had become proprietors of Hudson's Bay stock only eight and
forty hours before the general meeting. They were not indeed
possessed of it long enough to entitle them to vote at the meeting;
but their names now being entered in the Company's books, though
the ink was scarcely dry with which they were inserted, they felt
themselves competent to formally raise their voices in condemnation
of those measures which the committee of directors unanimously,
and the general court by a great majority, had approved of.
Their design in acquiring the Company's stock was obvious. However
circuitous the stratagem might be, it was clear that they had thus
become proprietors of one commercial company for the purpose of
advancing the fortunes of another, and a rival concern.[92] The
stratagem did not altogether fail, for Lord Selkirk's agents were yet
to encounter much friction in distant quarters supposed to be
friendly, and required to be obedient to the orders of the Company.
When the vote was taken, it was found that for the question there
appeared holders of stock valued at £29,937; against it, £14,823.
The Earl, himself, voted "for"—£4,087; the principal opponent of the
scheme being one William Thwaytes, whose interest was
represented at £9,233.
At this meeting a memorial was read violently opposing the scheme,
signed by Thwaytes and four or five others. According to them, the
main objections were:—(a) Impolitic; (b) Consideration inadequate;
(c) Grant asked for very large proportion of Company's holding, viz.:
70,000 square miles, or about 45,000,000 acres; (d) Should be a
public sale, if any, not a private contract with a member of the
Company; (e) No penalty for failure to find settlers; (f) Colonization
unfavourable to the fur-trade; private traffic would be carried on
with the United States of America.
The Earl proposed to find a number of effective men as servants to
the Hudson's Bay Company in return for a grant of land, viz., two
hundred men for ten years, from 1812, who would every year be
ready to embark between May 1st and July 1st at an appointed
place in Scotland.
The Company were to pay wages to each man not exceeding £20.
Should the Earl fail, he agreed to forfeit £10 per man short of two
hundred. As to proposed grants of land to settlers, two hundred
acres were to be given to labourers or artificers; one thousand acres
to a master of a trading-house. The Company were, of course, to
have full rights of access to all the surrendered districts.
Earl Selkirk's
proposal accepted.
The customs duties, exports and imports, payable
by settlers were not to exceed five per cent, at
Port Nelson, unless it happened that a higher duty
was levied at Quebec. The duties so to be levied were to be applied
to the expense of Government police, communication between Lake
Winnipeg and Port Nelson, etc., and not to be taken as profits for
the Company. The show of hands was in favour of the proposal; but
a protest was handed in to the Governor by Thwaytes and others. In
spite of this, on the 13th of June, the deed was signed, sealed and
delivered by the secretary on behalf of the Company.
The lands were defined by deed as situate between 52° 30' north
latitude and 102° 30' west longitude, a map being affixed to the
deed.
In reading this protest, one who was ignorant of the true state of
affairs would have been led to believe that the partners concerned
had no object so dear to them as the welfare and prosperity of the
Hudson's Bay Company. These gentlemen appeared to be animated
by the most thorough devotion and zeal, as they stood together
declaiming in loud, earnest tones against the errors into which their
beloved Company was falling, and pouring out their sympathy to the
emigrant settlers who might be lured to their destruction by
establishing themselves on the lands so granted "out of reach," to
employ their own phrase, "of all those aids and comforts which are
derived from civil society;" and so it did truly appear to many then
as it has done since. But let us examine those signatures, and lo, the
wolf obtrudes himself basking in the skin of a lamb!
The grant was thus confirmed. The opposition had found itself
powerless, and Selkirk was put into possession of a territory only
5,115 square miles less than the entire area of the United Kingdom
of Great Britain and Ireland.[93]
The grant secured, Selkirk at once despatched agents to Ireland and
throughout the highlands of Scotland, to engage servants, some for
the Company's service, others for general labourers in the colony.
Selkirk's immigrants
arrive.
These last were known as "his lordship's servants," and were
engaged for a term of years, at the expiration of which they became
entitled to one hundred acres of land, free of cost. They were placed
under the charge of Miles McDonnell, who received a joint
appointment from Selkirk and the Company, as first Governor of the
new colony.
The first section of the immigrant party arrived at
York Factory late in the autumn of 1811.[94] This
post was then in charge of William Auld, who, as
we have seen, occupied the position of Superintendent of the
Northern Department of Rupert's Land. After a short residence at the
fort, where they were treated in a somewhat tyrannical and high-
handed fashion by the Governor, who had scant sympathy for the
new régime, the party were sent forward to Seal Creek, fifty miles
up Nelson River. Governor McDonnell and one Hillier, in the character
of justice of the peace, accompanied them thither, and preparations
were at once made for the erection of a suitable shelter.
Stornaway.
(The Hebrides.)
McDonnell experienced a great deal of trouble during the winter with
the men under his charge, for a mutinous spirit broke out, and he
was put to his wits' end to enforce discipline. He put it all down to
the Glasgow servants. "These Glasgow rascals," he declared to Auld,
the Governor of York Factory, "have caused us both much trouble
and uneasiness. A more stubborn, litigious and cross-grained lot
were never put under any person's care. I cannot think that any
liberality of rum or rations could have availed to stop their
dissatisfaction. Army and navy discipline is the only thing fit to
manage such fierce spirits."
But the Irish of the party were hardly more tractable. On New Year's
night, 1812, a violent and unprovoked attack was made by some of
the Irish on a party of Orkneymen, who were celebrating the
occasion. Three of the latter were so severely beaten that for a
month the surgeon could not report their lives entirely out of danger.
Four of the Irishmen concerned in this assault were sent back home.
"Worthless blackguards," records the Governor; "the lash may make
them serviceable to the Government in the army or navy, but they
will never do for us."
On the subject of the Orkney servants of the Company all critics
were not agreed. Governor McDonnell's opinion, for instance, was
not flattering:—
"There cannot," he reported, "be much improvement made in the
country while the Orkneymen form the majority of labourers; they
are lazy, spiritless, and ill-disposed—wedded to old habits, strongly
prejudiced against any change, however beneficial. It was with the
utmost reluctance they could be prevailed on to drink the spruce
juice to save themselves from the scurvy; they think nothing of the
scurvy, as they are then idle, and their wages run on.... It is not
uncommon for an Orkneyman to consume six pounds or eight
pounds of meat in a day, and some have ate as much in a single
meal. This gluttonous appetite, they say, is occasioned by the cold. I
entirely discredit the assertion, as I think it rather to be natural to
themselves. All the labour I have seen these men do would scarcely
pay for the victuals they consume. With twenty-five men belonging
Opposition by the
Nor'-Westers.
to it, the factory was last winter distressed for firewood, and the
people sent to tent in the woods."[95]
Meanwhile, leaving the shivering immigrants,
distrustful of their officers and doubtful of what
the future had in store for them, to encamp at
Seal Creek, let us turn to the state of affairs amongst the parties
concerned elsewhere, particularly amongst the Nor'-Westers. Simon
McGillivray, who was agent in London for that Company, watched all
Selkirk's acts with the utmost distrust, and kept the partners
continually informed of the turn affairs were taking. He assured
them that Selkirk's philanthropy was all a cloak, designed to cover
up a scheme for the total extinction of the Hudson's Bay Company's
rivals. The colony was to be planted to ruin their trade. It was an
endeavour to check the physical superiority of the Nor'-Westers and
by means of this settlement secure to the Hudson's Bay Company
and to himself, not only the extensive and sole trade of the country
within their own territories, but a "safe and convenient stepping-
stone for monopolizing all the fur-trade of the Far West."
The partners in Montreal were stirred to action. Regarding Lord
Selkirk's motives in this light, they warmly disputed the validity of
the Hudson's Bay Company's Charter and of the grants of land made
to him. It was decided to bring all the forces of opposition they
possessed to bear on this "invasion of their hunting grounds."
The Bois-Brulés.
CHAPTER XXX.
1812-1815.
The Bois-Brulés—Simon McGillivray's Letter—Frightening the Settlers
—A second Brigade—Governor McDonnell's Manifesto—Defection
of Northmen to the Company—Robertson's Expedition to
Athabasca—Affairs at Red River—Cameron and McDonell in
uniform—Cuthbert Grant—Miles McDonnell arrested—Fort William
—News brought to the Northmen—Their confiscated account-
books—War of 1812 concluded.
There had lately been witnessed the rapid growth
of a new class—sprung from the loins of Red man
and European. Alert, rugged, turbulent, they
evinced at the same time a passionate love of the life and manners
of the wilderness, and a fierce intractability which could hardly fail to
cause occasional uneasiness in the minds of their masters. To this
class had been given the name of Métis, or Bois-Brulés. They were
principally the descendants of the French voyageurs of the North-
West concern, who had allied themselves with Indian women and
settled down on the shore of some lake or stream in the interior.
Amongst these half-breeds hunters and trappers came, and at a
later period a number of Englishmen and Scotchmen, hardly less
strongly linked to a wild, hardy life than themselves. These also took
Indian wives, and they and their children spoke of themselves as
neither English, Scotch, or Indian, but as belonging to the "New
Nation."
From 1812 to 1821 the North-West concern absorbed all the labours
and exacted the loyalty of the increasing class of Bois-Brulés. The
Hudson's Bay Company was exclusively an English company, and
their Scotch and English servants had left few traces of an alliance
with the aborigines. As the posts in the interior began to multiply,
and the men were thus cut off from the larger society which
obtained at York, Cumberland and Moose factories, and were thrown
more upon their own resources, a laxer discipline prevailed, and the
example of their neighbours was followed. A time was to come when
the "Orkney half-breeds" equalled in point of numbers those of the
French Bois-Brulés.
A Bois-Brulé.
There were yet few half-breeds of English extraction. The Bois-
Brulés were passionately attached to the North-West company, who
were quick to recognize their value as agents amongst the Indians.
The idea of nationality, so far from being frowned upon, was
encouraged amongst them. So much for the instruments which the
Company proposed to employ in Montreal.
It was only natural that amongst this rude race there should arise a
leader, a half-breed to whose superior ability and natural advantages
was added an education in Montreal, the seat of the co-partnery.
Cuthbert Grant, which was the name this individual bore, was known
Defections from the
North-West
Company.
far and wide amongst the hunters and trappers of Rupert's Land,
and everywhere commanded homage and respect. He had risen to
be one of the most enterprising and valued agents of the Nor'-
Westers, and was constantly admitted to their councils.
On the 22nd of May, 1811, at which period the matter was in
embryo in London, Simon McGillivray had frankly declared to Miles
McDonnell, agent to Lord Selkirk, that he was "determined to give all
the opposition in his power, whatever might be the consequences,"
because, in his opinion, "such a settlement struck at the root of the
North-West company, which it was intended to ruin."[96]
By way of argument, this gentleman took it upon himself to inform
the Hudson's Bay Company that the proposed settlement was
foredoomed to destruction, inasmuch as it "must at all times lie at
the mercy of the Indians," who would not be bound by treaties, and
that "one North-West Company's interpreter would be able at any
time to set the Indians against the settlers and destroy them."
Selkirk was now informed that there were several
clerks who had been many years in the service of
the Northmen, and who were disaffected in that
service. They grumbled at not having been sooner
promoted to the proprietary—that the claims of the old and faithful
were too often passed over for those of younger men of little
experience, because they were related to the partners. The Earl was
not slow to avail himself of this advantage. It became a matter of
importance to persuade as many as possible of these dissatisfied
spirits to join his scheme, by the offer of large salaries, and several
accepted his offer with alacrity. Amongst the most enterprising was
one Colin Robertson, a trader who had often ventured his life
amongst the tribes and half-breeds, to forward the interests of his
establishment. He possessed a perfect knowledge of the interior and
of the fur-trade, and to him Lord Selkirk entrusted the chief
management of the latter for the Company. Robertson was well
convinced of the superiority of the Canadian voyageurs over the
Orkneymen, in the management of canoes, for example, and he
proceeded to engage a number of them in Montreal at a much
higher wage than they had received hitherto.
To Robertson's counsels must be ascribed much of the invigoration
which now began to mark the policy of the Company. His letters to
the Company were full of a common-sense and a fighting spirit. "Let
us carry the trade to Athabasca," he said; and he proceeded to
demonstrate how all rivalry could be annihilated. The strength and
weakness of his rivals were familiar to him, and he was well aware
how much depended on the Indians themselves. They could and
would deal with whom they chose; Robertson determined they
should deal henceforth, not with the North-West, but with the
Hudson's Bay Company.
The Northmen had been for years continually pressing to the West.
They were doing a thriving trade on the Columbia River, in Oregon,
where they had a lucrative post; they had a post to the south of that
in California, and to the north as far as New Archangel. In the
second decade of the century the North-West Association had over
three hundred Canadians in its employ on the Pacific slope, sending
three or four ships annually to London by way of Cape Horn. In 1810
they had a competitor in the post of Astoria, founded by John Jacob
Astor, a fur-monopolist of New York. Astor had made overtures to
the North-West partners, which had been declined; whereupon he
induced about twenty Canadians to leave them and enter his service.
He despatched two expeditions, one overland and the other by sea,
around Cape Horn. But the founder of Astoria had not foreseen that
the breaking out of war between Great Britain and America would
upset all his plans. Fort Astoria, in the fortunes of war, changed
hands and became Fort George; and although the post was, by the
Treaty of Ghent, restored, the Canadians and Scotchmen had
returned to their old employers and interests. In a few years the
Hudson's Bay Company was to control the chief part of the fur-trade
of the Pacific Coast.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

More Related Content

PDF
Secure And Resilient Software Development Mark S Merkow Lakshmikanth Raghavan
PDF
Software Essentials Design and Construction 1st Edition Adair Dingle
PDF
Eclipse Rich Client Platform 2nd Edition Jeff Mcaffer
PDF
A Practical Guide to Database Design.pdf
PDF
Managing The Pstn Transformation A Blueprint For A Successful Migration To Ip...
PDF
Eclipse Rich Client Platform 2nd Edition Jeff Mcaffer
PDF
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
PDF
Introduction to Software Engineering 2nd Edition Ronald J. Leach
Secure And Resilient Software Development Mark S Merkow Lakshmikanth Raghavan
Software Essentials Design and Construction 1st Edition Adair Dingle
Eclipse Rich Client Platform 2nd Edition Jeff Mcaffer
A Practical Guide to Database Design.pdf
Managing The Pstn Transformation A Blueprint For A Successful Migration To Ip...
Eclipse Rich Client Platform 2nd Edition Jeff Mcaffer
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
Introduction to Software Engineering 2nd Edition Ronald J. Leach

Similar to Clientcentered Software Development The Cofoss Approach Tucker (20)

PDF
Introduction to Software Engineering 2nd Edition Ronald J. Leach
PDF
Cybersecurity A Practical Engineering Approach Henrique Santos
PDF
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
PDF
Project Management Theory and Practice 2nd Edition Richardson
PDF
Introduction to software engineering Second Edition Leach
PDF
Agile Software Development Susheela Hooda Vandana Mohindru Sood
PDF
Building Enterprise Systems With Odp An Introduction To Open Distributed Proc...
PDF
DSAPA.pdf
PDF
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
PDF
C Programming Fundamentals Dheeraj Malhotra Neha Malhotra
PDF
(Ebook) JavaScript Application Design: A Build First Approach by Nicolas Be...
PDF
Research Software Engineering A Guide To The Open Source Ecosystem Matthias B...
PDF
OpenGL Insights 1st Edition Patrick Cozzi
PDF
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
PDF
Rich client programming plugging into the NetBeans Platform 1. print Edition ...
PDF
Exam Ref 70413 Designing And Implementing A Server Infrastructure Steve Suehring
PDF
Acing The System Design Interview 1st Edition Zhiyong Tan
PDF
Adaptive Security Management Architecture 1st Edition James S. Tiller
PDF
The Abcs Of Ip Addressing 1st Edition Gilbert Held
PDF
Largescale Software Architecture A Practical Guide Using Uml 1st Edition Garland
Introduction to Software Engineering 2nd Edition Ronald J. Leach
Cybersecurity A Practical Engineering Approach Henrique Santos
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
Project Management Theory and Practice 2nd Edition Richardson
Introduction to software engineering Second Edition Leach
Agile Software Development Susheela Hooda Vandana Mohindru Sood
Building Enterprise Systems With Odp An Introduction To Open Distributed Proc...
DSAPA.pdf
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
C Programming Fundamentals Dheeraj Malhotra Neha Malhotra
(Ebook) JavaScript Application Design: A Build First Approach by Nicolas Be...
Research Software Engineering A Guide To The Open Source Ecosystem Matthias B...
OpenGL Insights 1st Edition Patrick Cozzi
Agile Software Development : Trends, Challenges and Applications 1st Edition ...
Rich client programming plugging into the NetBeans Platform 1. print Edition ...
Exam Ref 70413 Designing And Implementing A Server Infrastructure Steve Suehring
Acing The System Design Interview 1st Edition Zhiyong Tan
Adaptive Security Management Architecture 1st Edition James S. Tiller
The Abcs Of Ip Addressing 1st Edition Gilbert Held
Largescale Software Architecture A Practical Guide Using Uml 1st Edition Garland
Ad

Recently uploaded (20)

PPTX
GDM (1) (1).pptx small presentation for students
PDF
01-Introduction-to-Information-Management.pdf
PDF
Classroom Observation Tools for Teachers
PPTX
Cell Structure & Organelles in detailed.
PPTX
Institutional Correction lecture only . . .
PDF
Basic Mud Logging Guide for educational purpose
PPTX
Cell Types and Its function , kingdom of life
PDF
Module 4: Burden of Disease Tutorial Slides S2 2025
PPTX
Pharma ospi slides which help in ospi learning
PPTX
master seminar digital applications in india
PDF
Microbial disease of the cardiovascular and lymphatic systems
PDF
Anesthesia in Laparoscopic Surgery in India
PPTX
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
PPTX
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
PDF
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
PDF
FourierSeries-QuestionsWithAnswers(Part-A).pdf
PDF
Sports Quiz easy sports quiz sports quiz
PDF
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
GDM (1) (1).pptx small presentation for students
01-Introduction-to-Information-Management.pdf
Classroom Observation Tools for Teachers
Cell Structure & Organelles in detailed.
Institutional Correction lecture only . . .
Basic Mud Logging Guide for educational purpose
Cell Types and Its function , kingdom of life
Module 4: Burden of Disease Tutorial Slides S2 2025
Pharma ospi slides which help in ospi learning
master seminar digital applications in india
Microbial disease of the cardiovascular and lymphatic systems
Anesthesia in Laparoscopic Surgery in India
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
FourierSeries-QuestionsWithAnswers(Part-A).pdf
Sports Quiz easy sports quiz sports quiz
Black Hat USA 2025 - Micro ICS Summit - ICS/OT Threat Landscape
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
Ad

Clientcentered Software Development The Cofoss Approach Tucker

  • 1. Clientcentered Software Development The Cofoss Approach Tucker download https://ebookbell.com/product/clientcentered-software- development-the-cofoss-approach-tucker-10502608 Explore and download more ebooks at ebookbell.com
  • 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Clientcentered Business Consulting The Power Of Psychological Understanding Federico Addimando https://ebookbell.com/product/clientcentered-business-consulting-the- power-of-psychological-understanding-federico-addimando-52456066 The Clientcentered Law Firm Jack Newton https://ebookbell.com/product/the-clientcentered-law-firm-jack- newton-49427624 Contributions To Clientcentered Therapy And The Personcentered Approach Nathaniel J Raskin https://ebookbell.com/product/contributions-to-clientcentered-therapy- and-the-personcentered-approach-nathaniel-j-raskin-48402310 The Art Of Hypnotherapy Mastering Client Centered Techniques 4th Edition C Roy Hunter https://ebookbell.com/product/the-art-of-hypnotherapy-mastering- client-centered-techniques-4th-edition-c-roy-hunter-48880426
  • 3. Polyvagalexercises For Safety And Connection 50 Clientcentered Practices Norton Series On Interpersonal Neurobiology Deb Dana https://ebookbell.com/product/polyvagalexercises-for-safety-and- connection-50-clientcentered-practices-norton-series-on-interpersonal- neurobiology-deb-dana-43835790 Technology Tools For Todays Highmargin Practice How Clientcentered Financial Advisors Can Cut Paperwork Overhead And Wasted Hours David J Drucker https://ebookbell.com/product/technology-tools-for-todays-highmargin- practice-how-clientcentered-financial-advisors-can-cut-paperwork- overhead-and-wasted-hours-david-j-drucker-4313006 Adaptive Coaching The Art And Practice Of A Clientcentered Approach To Performance Improvement Terry R Bacon https://ebookbell.com/product/adaptive-coaching-the-art-and-practice- of-a-clientcentered-approach-to-performance-improvement-terry-r- bacon-1716678 The Heart Of Act Developing A Flexible Processbased And Clientcentered Practice Using Acceptance And Commitment Therapy Robyn D Walser https://ebookbell.com/product/the-heart-of-act-developing-a-flexible- processbased-and-clientcentered-practice-using-acceptance-and- commitment-therapy-robyn-d-walser-42758798 Gender Identity And Faith Clinical Postures Tools And Case Studies For Clientcentered Care Mark A Yarhouse https://ebookbell.com/product/gender-identity-and-faith-clinical- postures-tools-and-case-studies-for-clientcentered-care-mark-a- yarhouse-46368840
  • 9. CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 ⃝ c 2019 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed on acid-free paper International Standard Book Number-13: 978-1-138-58384-9 (Hardback) This book contains information obtained from authentic and highly regarded sources. Rea- sonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permis- sion to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, re- produced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Cen- ter, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not- for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trade- marks, and are used only for identification and explanation without intent to infringe. Library of Congress Cataloging-in-Publication Data Names: Tucker, Allen B., author. Title: Client-centered software development : the CO-FOSS approach / Allen B. Tucker. Description: Boca Raton, FL : CRC Press/Taylor & Francis Group, [2019] | Includes index. Identifiers: LCCN 2019010378| ISBN 9781138583849 (hardback : acid-free paper) | ISBN 9780429506468 (ebook) Subjects: LCSH: Application software--Development. | Computer software industry--Customer services. | Consumer satisfaction. Classification: LCC QA76.76.D47 T839 2019 | DDC 005.3--dc23 LC record available at https://lccn.loc.gov/2019010378 Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com
  • 10. To Meg, my inspiration and lifelong partner
  • 12. Contents List of Figures xvii List of Tables xxiii Foreword xxv Preface xxix Acknowledgments xxxv About the Author xxxvii Chapter 1 ■ The Journey 1 1.1 SOFTWARE 1 1.2 SOFTWARE DEVELOPMENT MODELS 3 1.2.1 Serial Development 3 1.2.2 Agile Development 4 1.2.3 CO-FOSS Development 5 1.2.4 Software Customization: A Continuum 7 Custom Software 7 Off-the-Shelf Software 8 Custom Software with Off-the-Shelf Components 9 1.3 SOFTWARE LICENSING 9 1.3.1 Proprietary Licensing 9 1.3.2 Open Source Licensing 10 1.3.3 FOSS Origins and Impact 13 FOSS Worldwide 16 Terminology: OSS, FOSS, FLOSS, H/FOSS, and CO-FOSS 18 vii
  • 13. viii ■ Contents 1.4 SOFTWARE ARCHITECTURES 19 1.4.1 Software Frameworks 19 1.4.2 Web Servers and Bundles 21 1.5 NEW VS MATURE OPEN SOURCE PROJECTS 22 1.5.1 Maturity Assessment 23 1.5.2 Incubation 24 Community 25 Bug Tracking 27 1.6 INTO THE WEEDS 28 1.6.1 To the Instructor 29 1.6.2 To the Student 31 1.6.3 To the Client 32 1.6.4 To the Developer 33 1.7 SUMMARY 33 1.8 MILESTONE 1 34 Section I Organization Stage Chapter 2 ■ Finding a Client and a Project 37 2.1 CLIENT ACTIVITIES AND SOFTWARE NEEDS 39 2.1.1 The Current Process and Existing Software 41 2.1.2 New Software to Fit a New Need 44 2.2 DOMAIN ANALYSIS 45 2.2.1 Requirements Gathering 48 2.2.2 User Stories 49 2.2.3 Use Cases 50 Unified Modeling Language 52 Writing an Effective Use Case 53 2.3 SOFTWARE DESIGN 55 2.3.1 System and Performance Requirements 55 2.3.2 Software Architecture 57 Layering, Cohesion, and Coupling 57 Domain Class Layer 61 Database Layer 61 User Interface Layer 63 2.3.3 Software Security 63 2.3.4 Encouraging Code Reuse 65
  • 14. Contents ■ ix 2.4 THE DESIGN DOCUMENT 66 2.4.1 Overall Structure 67 2.4.2 Variations 68 2.5 THE SANDBOX 69 2.6 SUMMARY 70 2.7 MILESTONE 2 70 Chapter 3 ■ Defining the Course 71 3.1 SOFTWARE PROJECT ELEMENTS 71 3.1.1 Collaboration Tools 72 3.1.2 Development Platform 73 3.1.3 Project Hosting 74 3.1.4 The Version Control System 75 3.1.5 Sandbox and Live Versions 77 3.1.6 Reading, Writing, and Documenting Code 79 3.1.7 Unit Testing 82 Unit Testing Tools 84 3.1.8 User Help 85 3.2 THE COURSE 86 3.2.1 The Classroom 87 3.2.2 Team Formation and Dynamics 88 3.2.3 Scheduling and Milestones 90 3.2.4 Ensuring Progress 92 3.2.5 The Syllabus 93 3.2.6 Assignments and Grading 95 3.2.7 Alternatives: The Two-Semester Software Projects Course 97 3.3 SUMMARY 98 3.4 MILESTONE 3 98 Section II Development Stage Chapter 4 ■ Project Launch 101 4.1 THE TEAM 101 4.1.1 Team Dynamics 103
  • 15. x ■ Contents 4.1.2 Asynchronous Communication 105 Aside: Mature FOSS Projects 106 4.1.3 Synchronous Communication 107 4.1.4 Shared Documents 108 4.2 THE DEVELOPMENT TOOLS 109 4.2.1 Programming Languages 109 JavaScript 110 Python 110 Java 111 Ruby 111 PHP 111 HTML and CSS 111 Other Languages 112 4.2.2 Software Platforms 112 The Apache/MySQL/PHP Server 113 Server-Side Java 114 Python 114 Ruby 114 4.2.3 IDEs for Development 114 Eclipse IDE 115 Python IDEs 116 Ruby IDEs 116 Java IDEs 116 Choosing and Installing an IDE 117 4.2.4 Working with the VCS 117 4.3 THE PRODUCT 122 4.3.1 Reading the Design Document 122 Identify Classes and Modules 124 Identify Instance Variables 124 Identify Methods and Functions 124 4.3.2 Reading the Code 126 Start from the Top 126 Look for Classes with Unique Keys 127 Avoid the Temptation to Edit the Code 128 4.3.3 Reading and Writing Code 129 4.3.4 Code Reuse 130 4.3.5 Licensing 131
  • 16. Contents ■ xi 4.4 SUMMARY 132 4.5 MILESTONE 4 132 Chapter 5 ■ Domain Class Development 133 5.1 CODING THE DOMAIN CLASSES 134 5.1.1 Reusing External Legacy Code 134 5.1.2 Reusing Internal Legacy Code 136 5.1.3 Coding a Domain Class from Scratch 137 5.1.4 Adding Functionality: Constructor and Getters 138 5.2 SOFTWARE TESTING 139 5.2.1 Test Case Design 141 5.2.2 Unit Testing Frameworks 142 5.2.3 Unit Testing the Homeroom Domain Classes 146 5.2.4 Unit Testing the Homebase Domain Classes 147 5.2.5 Code Synchronization and Integration Testing 151 5.3 DEBUGGING AND REFACTORING 154 5.3.1 Debugging 154 5.3.2 Identifying Bad Smells 156 Aside: Using Software Metrics 158 5.3.3 Refactoring 159 5.4 CLIENT REVIEW AND ISSUE TRACKING 162 5.4.1 Client Review 162 5.4.2 Issue Tracking 163 5.5 SUMMARY 164 5.6 MILESTONE 5 165 Chapter 6 ■ Database Development 167 6.1 DATABASE PRINCIPLES 168 6.1.1 Relations and Tables 169 Table Naming Conventions 170 6.1.2 Queries 172 6.1.3 Normalization 173 6.1.4 Keys 175 6.1.5 Concurrency Control 176
  • 17. xii ■ Contents 6.2 DATABASE ACCESS 177 6.2.1 Connecting the Program to the Database 178 6.2.2 Table Creation and Dropping 179 6.2.3 CRUD Functions 181 Create: Inserting Rows into a Table 182 Retrieving Rows from a Table 182 Update: Altering Rows in a Table 184 Delete: Removing Rows from a Table 185 6.2.4 Database Security 185 6.2.5 Database Integrity 187 6.2.6 Adding a Database Abstraction Layer 190 6.3 DATABASE TESTING 191 6.3.1 Testing the dbShifts.php Module 191 6.3.2 Testing the dbPersons.php Module 193 6.3.3 Testing the dbBookings.php Module 195 6.3.4 Testing the dbRooms.php Module 196 6.3.5 Integration Testing: Persons, Bookings, and Rooms 197 6.4 CLIENT REVIEW AND ISSUE TRACKING 200 6.4.1 Client Review 200 6.4.2 Issue Tracking 201 6.5 SUMMARY 205 6.6 MILESTONE 6 205 Chapter 7 ■ User Interface Development 207 7.1 PRINCIPLES 208 7.1.1 Model-View-Controller Pattern 209 MVC Example 1: Editing a Shift in Homebase 211 MVC Example 2: Editing a Person in Homeroom 212 MVC Example 3: Editing a Stop in Homeplate 213 7.1.2 Linkages among MVC triples 214 7.1.3 User-Level Security 216 User Login and Password Encryption 216 User Access Levels 218 Enforcement of Access Levels 218
  • 18. Contents ■ xiii 7.1.4 Protection against Outside Attacks 219 Avoiding SQL Injection Attacks 219 Avoiding Cross-Site Scripting Attacks 220 7.2 PRACTICE 221 7.2.1 Sessions, Query Strings, and Global Variables 221 7.2.2 Working with Scripts and HTML 223 Scripting Example 1: Editing a Shift 224 Scripting Example 2: Managing a Sub Call List 226 7.2.3 Reading Deeply 227 7.2.4 Using JavaScript and jQuery UI to Improve the User Interface 231 7.2.5 Responsive User Interfaces 234 Responsive user interface design 236 7.3 TESTING, DEBUGGING, AND REFACTORING 238 7.3.1 Testing a User Interface 240 Organizing the Testing Process 243 7.3.2 Refactoring: Removing a Layering Violation 243 7.4 ADDING A NEW FEATURE: ALL LAYERS IMPACTED 246 Changing the Edit Person MVC Triple 247 Changing the Search for Persons MVC Triple 248 Changing the Schedule Person MVC Triple 249 Changing the Edit Shift MVC Triple 250 Changing the Sub Call List MVC Triple 251 7.5 CLIENT REVIEW AND ISSUE TRACKING 252 7.5.1 A User Interface Bug 253 7.5.2 A Multi-Layer Bug 256 7.6 SUMMARY 258 7.7 MILESTONE 7 259 Chapter 8 ■ Preparing to Deploy 261 8.1 TECHNICAL WRITING 261 8.1.1 Writing for an Audience 262 8.1.2 Standards for Writing Quality 264 8.2 USER DOCUMENTATION 267 8.2.1 User Manuals, FAQs, and Demo Versions 267 Example: Firefox User Manual 269
  • 19. xiv ■ Contents Example: OpenMRS FAQ and Demo 270 Example: Homebase Demo 270 8.2.2 On-Line Help 271 8.2.3 Example: Homebase On-Line Help 273 Context-Sensitive Help 273 Help Table of Contents and Navigation 274 Help System Architecture 275 8.3 OTHER USER SUPPORT 278 8.3.1 User Training 278 8.3.2 Feedback Surveys 279 8.3.3 Final Presentations 280 8.4 CLOSURE FOR STUDENTS 281 8.4.1 Self-Assessment 281 8.4.2 Leveraging the CO-FOSS Experience 281 8.5 SUMMARY 282 8.6 MILESTONE 8 282 Section III Deployment Stage Chapter 9 ■ Continuing the Journey 287 9.1 TRANSITIONING TO PROFESSIONAL SUPPORT 287 9.1.1 The Hand-Off 288 9.1.2 Case Studies 289 Homebase Hand-Off and Support 289 RMHP-Homebase Hand-Off and Support 289 Homeroom Hand-Off and Support 290 Homeplate Hand-Off and Support 290 BMAC-Warehouse Hand-Off and Support 290 9.2 PROJECT EVALUATION AND CODE RELEASE 291 9.2.1 Potential New Clients 291 Volunteer and Resource Scheduling 291 Food Rescue and Redistribution 292 Agricultural Operations 293 9.2.2 Licensing Choices 293 9.2.3 Project Hosting Alternatives 294 GitHub 294
  • 20. Contents ■ xv GitLab 294 Bitbucket 295 SourceForge 295 9.2.4 Maturity Assessment 296 9.3 SOFTWARE MAINTENANCE AS A COMMUNITY ACTIVITY 298 9.3.1 Fixing Bugs: A Case Study 298 User-Developer Discussion 299 Debugging Activities 299 Developer-Developer Discussion 301 Closure 303 9.3.2 Software Maintenance: A Multi-Year Developer Perspective 304 Homebase Maintenance: 2010-2018 304 Homeplate Maintenance: 2012-2018 305 Homeroom Maintenance: 2013-2018 306 BMAC-Warehouse Maintenance: 2015-2018 307 RMHP-Homebase Maintenance: 2015-2018 308 9.4 CREATING A FORUM 308 9.4.1 Example: Wordpress Support Forums 309 9.4.2 Example: Firefox Forums 311 9.4.3 An Example Forum Exchange 312 9.5 EVOLVING INTO A DEMOCRATIC MERITOCRACY 312 9.5.1 Incubation 313 9.5.2 Organization 314 9.5.3 Task-Specific Roles 316 9.5.4 Oversight 317 9.5.5 Decision Making and Conflict Resolution 318 9.5.6 Domain Constraints 319 9.5.7 FOSS Project Foundations 320 9.6 SUMMARY 320 9.7 MILESTONE 9 321 9.8 ENDING THE JOURNEY 321 BIBLIOGRAPHY 323 INDEX 327
  • 22. List of Figures 1 The Triad. xxxi 2 The Three Stages of CO-FOSS Development. xxxi 1.1 The serial (waterfall) software development model. 4 1.2 An agile software development cycle. 5 1.3 The CO-FOSS software development model. 6 1.4 Relationships among common FOSS licenses. 12 1.5 Stand-Alone Computing. 19 1.6 Client-Server Framework. 20 1.7 Cloud Computing Framework. 20 1.8 Life cycle of a bug, from Bugzilla documentation, p 9. 28 2.1 RMH guest referral form (prior to 2011). 46 2.2 RMH guest registration card (prior to 2011). 47 2.3 RMH guest room log (prior to 2011). 48 2.4 Homeroom use cases. 53 2.5 Layered Architecture (↔ denotes information flow and → de- notes control flow). 58 2.6 Layered architecture of Homeroom. 59 2.7 Some of the initial domain classes for Homeroom. 61 2.8 dbRooms table structure in Homeroom database. 62 2.9 Room view screen draft for Homeroom. 64 2.10 Login Form for Restricting Homeroom Access. 64 3.1 The sandbox version: client-developer interaction. 78 3.2 Example code from Homeroom. 79 3.3 Output of the example code in Figure 3.2. 80 3.4 Inserting comments into the 2015 version of the Homebase Shift class. 81 xvii
  • 23. xviii ■ List of Figures 3.5 PHP documentation generated for the 2008 version of the Homebase Shift class. 83 3.6 Some of the functions in the Shift class for unit testing. 84 3.7 Elements of a unit test for the Shift class. 85 3.8 Results of running the TestShift unit test. 86 3.9 Form for filling a vacancy on a shift. 87 3.10 Help screen for filling a vacancy. 88 3.11 Assignment 3 in the BMAC-Warehouse project. 96 4.1 Developing Homeroom with the Eclipse IDE. 116 4.2 The code synchronization problem. 119 4.3 Resolving the problem: Copy-modify-merge. 120 4.4 Git Menu Options (on right) from within an Eclipse IDE. 121 4.5 Documentation practice using indented blocks and control structures. 130 4.6 Showing the open source license notice in the user interface. 131 4.7 Displaying the open source license notice in the source code. 131 5.1 Reusable Homebase Code in 2008. 136 5.2 Adapting the Code for Reuse in Homeroom in 2011. 137 5.3 Original Booking Class for Homeroom in 2011. 138 5.4 Revised Booking class for Homeroom in 2013. 139 5.5 Room class constructor and getters for Homeroom. 140 5.6 Test Suite in the Homeroom tests Directory. 143 5.7 Results of running a Test Suite. 143 5.8 A Unit Test for the Room Class in Homeroom. 144 5.9 Reporting a Unit Test Failure. 145 5.10 Setter Functions for the Room Class in Homeroom. 146 5.11 Partial unit test for the Booking Class in Homeroom. 148 5.12 The 2013 unit test for the Shift class. 149 5.13 The 2015 unit test for the Shift class. 150 5.14 New ApplicantScreening Class Added to Homebase in 2015. 151 5.15 New ApplicantScreening Unit Test added in 2015. 152 5.16 Interdependencies among Classes for Integration Testing. 153 5.17 A Recent GitHub Issue List for the Homeplate Project. 155 5.18 Example bad smell—duplicate code. 156 5.19 Example bad smell removal. 157
  • 24. List of Figures ■ xix 5.20 Searching the code base for all references to the get_address function. 160 6.1 A few rows in the dbDates table. 170 6.2 Homebase Shift class instance variables. 171 6.3 Attribute names and types in the dbShifts table. 172 6.4 The entries in the dbShifts table for August 6, 7, and 8, 2018 in Portland. 172 6.5 Connecting to the Homebase database. 179 6.6 Template for MySQLi table creation. 180 6.7 Creating the dbDates table in the Homebase database. 181 6.8 The phpMyAdmin tool for managing a MySQLi database. 181 6.9 Deleting a date from the dbDates table. 188 6.10 Retrieving a person from the dbPersons table in Homeroom. 189 6.11 A unit test for the dbShifts module. 192 6.12 Instance variables for the Person class in Homeroom. 193 6.13 A unit test for the dbPersons module. 194 6.14 Instance variables for the Booking class in Homeroom. 195 6.15 Portions of a unit test for the dbBookings.php module. 196 6.16 Instance variables for the Room class in Homeroom. 197 6.17 A unit test for the dbRooms.php module. 198 6.18 An integration test for dbPersons.php, dbBookings.php, and dbRooms.php. 199 6.19 The first 6 issues posted for the 2015 Homebase project. 201 6.20 Simple framework for posting a new issue. 202 6.21 Form for posting a new issue on a GitHub project. 203 7.1 The Model-View-Controller pattern. 210 7.2 The Edit Shift view in Homebase. 211 7.3 The Person Edit view in Homeroom. 212 7.4 The Stop view in Homeplate. 213 7.5 The main menu views in (a) Homebase, (b) Homeroom, and (c) Homeplate. 214 7.6 Part of the view and controller for the main menu MVC in Homebase. 215 7.7 The View and Controller for the Homebase login form. 217 7.8 Ensuring security in Homebase using $_POST and $_SESSION variables. 219
  • 25. xx ■ List of Figures 7.9 Controlling navigation using $˙POST variables. 224 7.10 Excerpts from editShift.php view and controller module. 225 7.11 Underlying view and controller for managing a SubCallList. 227 7.12 Using the SubCallList form. 228 7.13 Code snippet for removing a person from a Shift. 230 7.14 Essential steps for deleting a Shift from the dbShifts table. 231 7.15 Essential steps for inserting a Shift into the dbShifts table. 232 7.16 Coding calendar date using HTML selects. 233 7.17 Coding calendar date using a jQuery UI datepicker widget. 234 7.18 A Responsive user interface. 235 7.19 The Homeplate Mobile home screen. 236 7.20 A responsive user interface view. 238 7.21 HTML code underlying part of the view in Figure 7.20. 239 7.22 The Calendar view inside Homebase Use Case 4. 241 7.23 Layering Violation: a user interface module directly querying the database. 244 7.24 Layering Violation fixed and bad smell removed. 246 7.25 Showing a person’s status in the Edit Person view. 248 7.26 Coding to show a person’s status in the Edit Person view. 248 7.27 Updating a database entry with the new status field. 249 7.28 Searching for “applicant” status. 249 7.29 Search results for status = “applicant”. 250 7.30 searchPeople.php code for selecting a person’s type. 250 7.31 Listing only “active” volunteers when filling a vacancy. 251 7.32 Changing editMasterSchedule.php to list “active” volunteers. 251 7.33 Selecting only active volunteers for filling a calendar vacancy. 252 7.34 Code for selecting only active volunteers. 252 7.35 Issues 7-16 posted for the 2015 Homebase project. 254 7.36 Locating a bug in the calendar.php module. 255 7.37 The process_edit_notes function inside calendar.inc. 257 7.38 Locating a bug in the dbDates module. 258 8.1 First page of the Firefox user manual, including Help link. 269 8.2 The Introductory OpenMRS FAQ List. 270 8.3 The OpenMRS on-line demo. 271 8.4 The Homebase on-line demo. 272 8.5 Context-sensitive help for the search page. 273
  • 26. List of Figures ■ xxi 8.6 The first two steps in the Searching for People help page. 274 8.7 Enlarged thumbnail in Step 2 of Searching for People. 274 8.8 The on-line help table of contents in Homebase. 275 8.9 Integrating help pages within the code base. 276 8.10 HTML code for Step 2 in the help file searchPersonHelp.inc.php. 277 9.1 Reproducing the bug. 300 9.2 Locating the defect. 300 9.3 Designing the fix. 301 9.4 Testing the fix: editing a person. 302 9.5 Points of access to the Wordpress forums. 310 9.6 Snapshot of the Installing Wordpress Forum. 310 9.7 Accessing the Firefox user forum. 311 9.8 Organizational levels in the Sahana project. 317
  • 28. List of Tables 2.1 Process a Referral. 54 2.2 Overall Structure of a Design Document. 67 3.1 A few PHPDoc Tags and their Meanings. 82 3.2 Example Course Syllabus Schedule: Spring 2015 Semester. 94 4.1 Overall Structure of the Homeroom Code Base. 127 6.1 Relations in SQL Queries. 173 6.2 Redesigning the dbShifts table to improve normalization. 175 6.3 Programming Language Database Extensions for SQL. 178 6.4 Common Attribute Types in MySQLi Tables. 180 7.1 CRUD Functions in the dbShifts module. 230 7.2 The three views in the Editing the Calendar use case. 240 7.3 MVC steps for adding a new feature. 247 8.1 Homebase User Questionnaire and Results. 279 8.2 Agenda for a Final Presentation. 280 xxiii
  • 30. Foreword Client-Centered Software Development: The CO-FOSS Approach provides a much needed guide and resource for undergraduate software development or capstone courses that seek to engage students in a real-world software- development project. Such a course offers unique and daunting challenges. As someone who has taught such a course intermittently over my 30+ year career, the goal was always to give students a real sense of what software development is like. But the challenges are many. How do you identify a project that can be done and done well in a 14-week semester? How do you manage teams of undergraduate CS majors, with different skill sets and motivations? What combination of platforms and software tools can be used effectively under such constraints? How do you evaluate student effort and contributions? What happens to the “product” once the semester ends? These are just some of the issues. In this book, Allen Tucker has laid out a well-tested and practical model for addressing these challenges. The development approach is called CO-FOSS, which stands for client-oriented software development using free and open source software. The class project involves developing and deploying a soft- ware product for an actual client, which is typically a local non-profit or- ganization that needs mission critical software but cannot afford to hire a professional software-development company. The software platform and tools used in the project are all freely available and openly licensed. The book is full of instructive examples that cover all of the parts and stages of a substantial software-development project. It ends with a practical and innovative model for supporting the student-built product after the semester has ended. This is very important – many of the software-development projects one finds in undergraduate courses end up sitting on shelves. It’s great to see the evolution of the type of FOSS-development course that this book describes. Ten years ago or so, I and other faculty tried to organize such courses under the banner of the Humanitarian Free and Open Source Software project (HFOSS). The idea then was to get students involved with existing FOSS projects, particularly those that served “humanitarian” purposes. The goal was to teach students about FOSS development – some- thing that was not typically part of the CS curriculum at the time – by getting them engaged as contributors to some real FOSS projects. We collab- orated with the Sahana project (a disaster management system), OpenMRS (a medical records system), GNOME (Linux-based accessibility software), TOR xxv
  • 31. xxvi ■ Foreword (privacy-based browser software), the Mozilla project, and others. While we had many successes, and while many students made significant contributions to these projects, the logistics of managing collaboration with such projects within a one-semester course proved difficult. The CO-FOSS model addresses the challenges that the HFOSS approach faced in creative and practical ways. This book shows that you really can get students involved in meaningful FOSS development in a one-semester course. The book is organized into three main parts. The Organization Stage sec- tion is written primarily for the instructor and provides practical advice on identifying a client and creating a plan for a doable software product that would help that client, as well as constructing the syllabus for the course. A key part of the syllabus is a carefully thought-out sequence of milestones that, if followed, will lead to successful completion of the project. The Development Stage section is written primarily for students and is meant to be read and followed during the semester. It concisely covers all of the main elements of software development with numerous practical ex- amples: creating development teams, object-oriented design, database design, user-interface design and development, software documentation, and support. Among other things, this section has brief but authoritative discussions of: • FOSS licensing • The LAMP, MAMP, and WAMP server stack – i.e., Linux, Apache, MySQL, and PHP • Software hosting (e.g., GitHub) and issue tracking • Communication software such as Skype and Slack • Creating and using unit tests for all parts of the software • Principles of Model-View-Controller design • Effective debugging tools and strategies • IDEs for various programming languages, including PHP, Python, Ruby, and Java • Database essentials, including normalization and CRUD functions • Principles of software security • Writing useful documentation and user-help features Each of these topics is supported with helpful examples, including many code snippets, taken from successful CO-FOSS projects that Allen and oth- ers have conducted at various undergraduate institutions, including Bowdoin College, Dickinson College, University of New Hampshire, Whitman College, and others. Importantly, the projects created at these schools are hosted on
  • 32. Foreword ■ xxvii GitHub, and available to be used as models or even templates, depending on the type of software product a client needs. The Deployment Stage section describes how to transition the product from the classroom to professional support so that the product can live on. An important feature of this section is the role played by the Non-Profit FOSS Institute (NPFI), an organization started by Allen that provides help in identifying and supporting professionals who can realistically be expected to host the software and manage its ongoing debugging and support. When no such professionals can be found, NPFI shoulders some of these tasks itself. This is an incredibly powerful resource, which has the potential to make all the difference between a class project that dies once the class ends and a software product that truly adds value to the client’s mission. Some other important features of the book include: • Milestones: Each of the nine chapters include a short list of milestones. These serve both as a means of keeping the project on track, and also as assignments that can serve as the basis for evaluating student work. • Course organization: In addition to providing a template that can be used to model the course syllabus, the book provides helpful ideas on how to evaluate student work. Like other parts of the book, these have the benefit of being based on courses that have tried and tested many of the ideas in the book. Designing and implementing a software-development course in an under- graduate CS program can be intimidating. It exposes the instructor to risks not found in other courses: Will he or she be able to manage the relationship with the client? Will the students be able to create a quality piece of software, and will they see it as an important education experience? Will the instructor receive credit for taking such risks and going beyond the usual course expecta- tions? On this last point, it is worth noting that more and more schools seem to be encouraging “community involvement,” and many have set up centers designed to serve as interfaces between town and gown. The model described in this book would fit in well with such institutional initiatives. This book provides a workable model that helps mitigate some of these worries. The projects used as examples throughout the book serve as a proof of concept for what can be done, and the book itself serves as a step-by-step guide to getting it done. If you are considering an undergraduate software- development course that teaches the principles of FOSS development, you won’t go wrong by starting with this book. Ralph Morelli Professor of Computer Science (Emeritus) Trinity College Hartford, CT April 20, 2019
  • 34. Preface Software development is a complex and dynamic field. Its complexity appears in many forms – the sheer variety of software clients and applications, the rapid evolution of software development tools, the wide range of skills among professional developers, the rapid evolution of computing platforms, and the diversity of strategies used to develop the software itself. This book is about one particular strategy for software development called the “CO-FOSS approach.” The term CO-FOSS is short for “Client-Oriented Free and Open Source Software.” A project using the CO-FOSS approach aims to develop a customized software product for a single client, either from scratch or (more likely) by reusing open source components from prior projects.1 The client for a CO-FOSS project is typically a non-profit humanitar- ian, educational, or public service organization, such as a Ronald McDonald House, a local school system, a Habitat ReStore, a food distribution organiza- tion, or a senior center. The key here is that the client has a genuine need for new software that will streamline a mission-critical operation, such as volun- teer calendar scheduling, inventory management, donation tracking, or room scheduling. The CO-FOSS approach has been evolving since 2008. It has been used in intermediate and capstone undergraduate computing courses where teams of students learned the principles of software development while they gained practical experience implementing a real-world software product. The key dis- tinction for CO-FOSS in this setting is that the software product itself is real: the students are developing it for a real client, so both the risks and the re- wards are high in comparison with a more traditional software development course with no real product. Organizing such a course requires an unusual effort by the instructor. Be- cause some of this effort may be unrewarded by typical institutional measures for excellence in teaching, the instructor must view the benefits of taking this “outside the box” approach as worthwhile. Additional support for making this 1The term “CO-FOSS” was coined in a 2014 study by MacKellar, Sabin, and Tucker [25], which discusses the results of using this approach in courses at three different types of institutions. The original idea of “client-oriented FOSS” was presented in a 2011 book by Tucker, Morelli, and de Silva [43], where it was contrasted with the idea of “community- oriented FOSS.” While both ideas engage students with FOSS development, the latter creates a more generic product that is not customized for a single client. xxix
  • 35. xxx ■ Preface extra effort may come from the instructor’s home institution or from various outside sources such as the Non-Profit FOSS Institute.2 Our experiences with the CO-FOSS approach have yielded the following benefits: 1. Undergraduate computing students are uniquely motivated by commu- nity service experiences that are embedded within their formal academic training. Uniformly, they report great satisfaction when using their com- puting skills to develop software that serves the larger community (e.g. the page https://npfi.org/student_evaluations/ shows the com- plete student evaluations for the software development course taught at Whitman College in 2015). 2. Client organizations benefit by receiving free customized software that directly supports their mission-critical activities. For example, the Ronald McDonald House in Providence, RI received volunteer database and scheduling software called Homebase developed by a 5-student team in that 2015 Whitman College course (see https://npfi.org/ projects/the-rmhp-homebase-project/). That software is still in use today. 3. The fact that a CO-FOSS product is free and open source software allows any of its source code to be reused and refitted to suit the needs of a fu- ture project. For example, the Homebase software mentioned above was adapted from an earlier version developed in 2013 by Bowdoin Col- lege students for the Ronald McDonald House in Portland, ME. Thus, an open source license like the GNU General Public License or the Mozilla Public License is an essential element of the CO-FOSS approach. 4. Students gain experience learning about key elements of the software development process, including coding, testing, refactoring, and writing user documentation, as they would in a conventional software devel- opment course. However, these students also gain practical experience by working within a team, communicating with a client, using a client- centered development model, sharing a code base, and reusing legacy code – experience that prepares them well for entry into the modern software industry. This book aims to provide instructors, students, clients, and professional software developers with a roadmap to guide them through the development of a new CO-FOSS product from conceptualization to deployment. We use 2Throughout this book, any word or phrase that appears in typewriter font represents a link to a Web page that provides more details. Of course, those links work only for the e-book version. Readers using the print version should be able to locate most of these Web pages by doing a Google search for that word or phrase.
  • 36. Preface ■ xxxi our own experiences with this approach to illustrate each step in the process, detailing its technical elements, its methodologies, and its outcomes.3 The CO-FOSS approach views each project as having three connected el- ements that form a triad, as pictured in Figure 1. The student team is one element of the triad, the client is the second, and the professional developer is the third. The goal of a triad is to design, implement and deploy a cus- tomized software product that supports a specific mission-critical activity of the client.4 FIGURE 1 The Triad. The instructor is involved in all three ele- ments of a CO-FOSS project. The instructor organizes it, leads the student team through project development, and delivers the completed software product to the professional. The stu- dents, who are intermediate-level computing ma- jors, develop the software using both the require- ments document and a client-centered approach. The professional installs the completed software on the client’s server, and then provides ongoing support thereafter.5 The project has three stages: a 2-month or- ganization stage, a 3-month development stage, and a 1-month deployment stage, as shown in Figure 2. FIGURE 2 The Three Stages of CO-FOSS Development. So the instructor provides the glue that holds these three stages together, as outlined below: 3All the examples in this book use the PHP/Javascript/MySQL/HTML platform, since that is the platform on which our own CO-FOSS projects were built. So while instructors may find the organizational aspects of this book to be useful, this book may be supplemented by reference materials that uses a different platform, such as Django or Rails. 4Absent the student team, a CO-FOSS product can always be designed, implemented, and deployed by a professional developer working directly with the client. 5Because the requirements and the design document are prepared during the organiza- tion stage, the course itself should be properly labeled “software development” rather than “software design.”
  • 37. xxxii ■ Preface 1. During the organization stage, the instructor identifies the client’s mission-critical software need, and then develops the requirements for a software product that will fulfill that need. This includes eliciting an ini- tial set of use cases from the client, developing an initial design document and course syllabus that has an implementation timeline embedded, and forming the student team. 2. During the development stage, the instructor, student team, and client representative use a client-centered process to create a software product that fulfills the requirements. That is, in a 1-semester course, the team iteratively develops the product and refines the requirements, taking into account the client’s feedback at each iteration.6 3. During the deployment stage, the instructor turns the product over to the developer who installs the product on the client’s server (website). Here, the developer and the client also collaborate to iron out any linger- ing issues for the product and agree on a long-term support plan going forward.7 To introduce the CO-FOSS approach, this book has an introductory chap- ter followed by three Parts. The introductory chapter provides an overview of software, open source licensing, and major software development methodolo- gies. Everyone should read this chapter first and complete Milestone 1 at the end of the chapter before continuing. Each Part thereafter explores one of these three stages by sharing our knowledge of designing, developing, and deploying a CO-FOSS product using the triad as an organizational framework. Part I is written mainly for the instructor and secondarily for the client. It covers the details of finding a client and a CO-FOSS product to be de- veloped, defining that product’s requirements, and organizing a course in which students can develop the product. The instructor should complete Milestones 2 and 3 before continuing to Part II. Part II comprises the bulk of the book and is written mainly for the in- structor and the students. It covers the principles and practice of client- centered software development, with many examples from CO-FOSS projects that our students have completed in recent years. The chapters 6We know of several CO-FOSS courses that spread the project’s development stage over two semesters, either with the same group of students or with two different groups of students. In one case, two different groups of students worked on the same project in successive offerings of the same course. In another case, the same group of students worked on the project over a unified 2-semester capstone “Software Projects” course. Both of these approaches are viable when the institutional setting allows that flexibility. 7The recent rise of Web application hosting services, often called ‘‘platform as a service" or PaaS, may reduce or eliminate the need for a professional developer to be involved in the deployment stage. In this case, the instructor should be willing to maintain the software after the project has been deployed.
  • 38. Preface ■ xxxiii in Part II should normally be taken in order, and each chapter’s own Milestone should be completed before continuing to the next chapter. Part III is written mainly for the instructor and the professional devel- oper, providing guidance on deploying a new CO-FOSS product, sup- porting it, and disseminating it to the larger open source community. The last Milestone appears at the end of this chapter and its comple- tion signals completion of the entire project. The Table of Contents shows how the chapters are laid out in each of these three Parts. Of course, the devil is in the details, so let’s get started!
  • 40. Acknowledgments The CO-FOSS approach to software development is people-intensive. I am fortunate to have worked with many extraordinary people who have con- tributed to the CO-FOSS projects described in this book. I gratefully acknowledge: The student developers at Bowdoin and Whitman Colleges, for their will- ingness to make the connection between academic work and community service by completing these projects successfully: Adrienne Beebe, Hartley Brody, James Cook, Johnny Coster, Moustafa El Badry, Felix Emiliano, Connor Hargus, Jerrick Hoang, Richardo Hopkins, Noah Jensen, Phuong Le, Alex Lucyk, Dylan Martin, Ruben Martinez, Nolan McNair, Jackson Moniaga, Je- sus Navarro, Luis Munguia Orta, Maxwell Palmer, David Phipps, David Quen- noz, Oliver Radwan, Sam Roberts, Luis Rojas, Taylor Talmage, Xun Wang, Nicholas Wetzel, Ivy Xing, and Judy Yang. The non-profit clients, for providing real-world settings in which the software could be developed, customized, and deployed: The Blue Mountain Action Council of Washington (Kathy Covey and Jeff Mathias); Ronald Mc- Donald House Charities of Maine (Gabrielle Booth, Robin Chibroski, Geor- gia Doucette, Whitney Linscott, Ashley MacMillan, Alicia Milne, Gretchen Noonan, Karla Prouty, and Raymond Ruby); Ronald McDonald House Char- ities of Rhode Island (Susan Czekalski, Michelle LePage, and Joanna Pow- ers); and Second Helpings of South Carolina (Bruce Algar, Lili Coleman, and Jon Peluso). The professional developers, for supporting the software on the clients’ servers: Artopa LLC (David Tripp), Coursevector LLC, The Non-Profit FOSS Institute, Pragmatics, Inc. (Dr. Long Nguyen), and Vivio Technologies, Inc. My faculty colleagues, for helping me understand the challenges of teaching FOSS development as an academic and humanitarian enterprise: Jim Bowring, Grant Braught, Janet Davis, Greg Hislop, Steve Huss- Lederman, Bonnie MacKellar, Craig McEwen, Ralph Morelli, and Mihaela Sabin. The reviewers of this manuscript, for providing a wealth of conceptual and detailed suggestions for improving it: Jim Bowring, Janet Davis, and Steve Huss-Lederman. xxxv
  • 41. xxxvi ■ Acknowledgments Dr. Jennifer Tucker, for helping me develop the idea of the Non-Profit FOSS Institute, and then serving as its first Executive Director. And finally my wife, Meg, for her lifelong commitment to education and humanitarian volunteerism, and especially for introducing me to the first CO-FOSS client at the Ronald McDonald House in Portland, ME in 2007. Allen B. Tucker, February 2019
  • 42. About the Author Allen B. Tucker is the Anne T. and Robert M. Bass Professor Emeritus in the Department of Computer Science at Bowdoin College. He held similar po- sitions at Colgate and Georgetown Universities. He is currently a professional software developer and President of the Non-Profit FOSS Institute (NPFI), a 501(c)(3) organization that supports the development of free open source software for non-profits by students and professionals. Allen earned a BA in mathematics from Wesleyan University and an MS and PhD in computer science from Northwestern University. He is the author or coauthor of several books and articles in the areas of programming lan- guages, software design, natural language processing, and computer science education. He co-authored the 1986 Liberal Arts Model Curriculum in Com- puter Science, served as Editor-in-Chief of the Handbook of Computer Science, and co-authored the textbooks Programming Languages and Software Devel- opment. He also served as Fulbright Lecturer at the Ternopil Academy of National Economy in Ukraine, a visiting Erskine Lecturer at the University of Canterbury in New Zealand, a Visiting Lecturer at ESIGELEC in France, and a Visiting Professor at Whitman College. Allen has been a member of NSF’s CISE Advisory Board, the Association for Computing Machinery (ACM), the IEEE Computer Society, Computer Professionals for Social Responsibility, and the Liberal Arts Computer Science (LACS) Consortium. In 1991, he received the ACM Outstanding Contribution Award and shared the IEEE Meritorious Service Award. He is also a Fellow of the ACM and a recipient of the ACM SIGCSE Award for Outstanding Contributions to Computer Science Education. From 2008 to 2012, Allen served on the Advisory Board for the NSF CPATH grant that supported Trinity, Wesleyan, and Connecticut College’s Humanitarian Free and Open Source Software (HFOSS) initiative. That ex- perience inspired him to begin engaging his own Bowdoin students in HFOSS and developing a curricular model called CO-FOSS (client-oriented FOSS) with his colleague Ralph Morelli at Trinity College. From 2008 to 2015, he taught several software-development courses at Bowdoin and Whitman Colleges using the CO-FOSS model with different student teams. As a byproduct of this work, he developed strong working relationships with non-profits such as the Ronald McDonald Houses in Maine and Rhode Island, and food distribution organizations in South Carolina and Washington. xxxvii
  • 43. xxxviii ■ About the Author In 2013, with the belief that the CO-FOSS model would be viable in a large number of undergraduate settings, Allen co-founded NPFI. NPFI’s mission is to spread the development and deployment of open source CO-FOSS products, teaching methods, grants, and other resources to other computing faculty, so that they can engage their own students with real-world HFOSS development for many more non-profit organizations in the future.
  • 44. C H A P T E R 1 The Journey “Change your opinions, keep your principles; Change your leaves, keep intact your roots.” —Victor Hugo This chapter provides an overview of software — its nature, its development models, its licensing alternatives, its architectures, and its maturity. Thus it offers a useful perspective within which the development of a new software product can be viewed. CO-FOSS is a model for developing new software. It is a particularly valu- able model, both for learning about the software process and for developing an actual software product for a real client. To provide a broader context, Section 1.2 discusses three different software development models: the serial model, the agile model, and the CO-FOSS model. Fundamental to CO-FOSS development is the free and open source li- cense that accompanies the software itself. Without such freedom, CO-FOSS development would not be possible. This idea is discussed more carefully in Section 1.3. A key characteristic of any software product is its underlying architecture, or organization. A coherent architecture is always an essential component of all but the most simple software products. Section 1.4 introduces the client- server family of software architectures that underly the organization of many CO-FOSS products. Different software products also vary in their maturity. The idea of CO- FOSS applies mainly to the development of new software, often from pre- existing components. However, most software is more mature, having evolved through various levels of maturity over its lifespan. Section 1.5 looks at this larger temporal context in which CO-FOSS development lies. 1.1 SOFTWARE Simplistically, “software” can be viewed as all the programming in a computer that is not hardware. But the very idea of “software” is a complex one. Even 1
  • 45. 2 ■ Client-Centered Software Development: The CO-FOSS Approach the software on a single computer exists at two distinct levels – the operating system/network level (think Linux, Windows, MacOS, or Apache Server) and the application level (think Microsoft Office, OpenOffice, the Chrome browser, or the Google Maps application). Professional software developers have skills that reflect the level and type of software that they develop. For example, Linux and network software de- velopers work at the operating system/network level. Their skills allow them to work with such tools and techniques as C programming and process syn- chronization. Other professional software developers work at the application level, such as Web programming or database design, which requires a different set of skills. The application level alone spans a wide range of distinct areas, each of which has its own community of developers. Here’s just one taxonomy of software application areas that appears in Wikipedia: Information systems software supports corporate payroll, account- ing, and inventory management, and individual word processing, spread- sheet, and visual presentation needs. Entertainment software includes video games, mobile games, and social networks. Educational software includes course management, survey manage- ment, and language learning support. Enterprise infrastructure software includes project management, database systems, document management, and content managed web- sites. Simulation software simulates social networks, battlefield scenarios, airline flight control, and vehicle driving control. Media development software includes computer graphics and ani- mation, graphic art, image galleries, audio and video editing, and digital music generation. Product engineering software includes compilers, interpreters, vir- tual machines, computer aided design tools, integrated development en- vironments (IDEs), version control systems (VCS), and debuggers. How big is the software industry? The number of professionals in this industry is large and growing. A recent study estimated that there were 21 million software developers worldwide in 2016. Of those, nearly 4 mil- lion worked in the United States, and they comprised 2.5% of the total US workforce. At the same time, demand for software professionals greatly exceeds supply, creating a favorable job market for new developers who are completing computer science, IT, and computer engineering degree programs.
  • 46. The Journey ■ 3 1.2 SOFTWARE DEVELOPMENT MODELS Software is also complex in the sense that a software product can be developed using different methodologies, or “development models.” On the one hand, it can be developed serially, starting from a fixed set of requirements, proceeding to a design specification, followed by writing the code and finally testing the code. On the other hand, it can be developed from the “bottom up,” start- ing with a small prototype and incrementally adding new requirements and functionality with each iteration. Additionally, some software can be developed as a generic product for a large (real or imagined) market, while other software can be developed as a customized product for a single client. The former approach is potentially more profitable, while the latter approach is useful for an organization that has unique software needs that are unmet by commercially-available software. Finally, software can be developed from scratch (sometimes called a “green- field” project), or it can be developed incrementally using pieces of code bor- rowed from other software with similar features (a “brownfield project”). This section briefly addresses three different software development models, their constraints, and their tradeoffs. 1.2.1 Serial Development The serial approach to developing software originated as the so-called “wa- terfall model,” and it was the predominant approach to developing software throughout the 1970s and 1980s. It is based on the assumption that a software product’s functional requirements can be fully specified at the outset, and that subsequent stages in the development process can be carried out more-or-less serially. These stages are called “requirements analysis,” “design,” “coding,” “testing,” and “delivery.” Each stage in this process is viewed as a single discrete event. One stage typically does not begin until the previous stage is completed. Typically, the client is involved in the beginning and ending stages, but not in the crucial middle stages. This is illustrated in Figure 1.1. If the requirements can be fully specified at the outset, the serial model can work. For example, an embedded software module that measures and reports the altitude of an airplane in real time can be designed and implemented using this model. However, this serial approach to software development has had a poor record of success in completing software products for customers. For example, the 2015 Chaos Report [19] surveyed 50,000 software projects around the world to learn how well they met the following three criteria: 1. completed on time, 2. completed on budget, and 3. completed with all features implemented.
  • 47. 4 ■ Client-Centered Software Development: The CO-FOSS Approach FIGURE 1.1 The serial (waterfall) software development model. The Chaos Report found that only 11% of all projects using the traditional serial model met all three criteria, while 60% were “challenged” (that is, they were completed but did not meet all three criteria), and the remaining 29% failed (that is, they were never completed). So in many situations, the serial development model does not work well. Its main problem lies in the assumption that the requirements of a software prod- uct can be fully specified at the outset, and that those requirements will not vary throughout the development process. In reality, various outside factors (such as changing user needs or the emergence of a new computing platform) can alter the requirements. For example, the 2015 Chaos Report [19] confirmed that not incorporating end users’ feedback throughout the development pro- cess was a frequent cause for software project failure. 1.2.2 Agile Development Since the 1990s, and in response to these problems, software development methodologies have been gradually evolving away from the serial model. Newer methodologies known as “rapid application development,” “dynamic systems development,” “scrum,” “extreme programming,” and “feature-driven devel- opment” have been shown to be more effective in settings where changing user requirements or computing platforms had become the norm. These newer methodologies all led to the 2001 publication of the Manifesto for Agile Soft- ware Development [5], which crystallized them into a coherent statement of principles and a development model. In recent years, the agile model and its variants have yielded significant improvements over the traditional serial model. For example, the same 2015 Chaos Report [19] found that 39% of all projects that used the agile model met all three of the above criteria for success, while 52% were challenged and only 9% failed. The main reasons for its improved success rate are explained by the nature of the agile process itself. In an agile project, the software product starts with
  • 48. The Journey ■ 5 a minimal set of requirements and iterates several times through a 6-stage development cycle, as pictured in Figure 1.2. The process is fluid, in the sense that each cycle improves the requirements and develops new code in response to client feedback from reviewing the results of the previous cycle. FIGURE 1.2 An agile software development cycle. Let’s look at some of the details in the agile cycle. In stage 1, the developers Meet with the client and discuss the client Review of the partially-completed software from stage 6 of the previous cycle. In stage 2, the developers and client assume new Tasks for making progress by adding new functionality and in- corporating the client’s feedback from stage 1. Developers then independently complete their respective Design, Code, and Test stages, thus preparing the next version of the partially-completed software for client Review. 1.2.3 CO-FOSS Development The CO-FOSS model for developing software is a hybrid of the serial and agile models for software development. It borrows pieces from both, as summarized in Figure 1.3. To enable students to develop a useful piece of software for a single client in one semester, the software Design is organized by the instructor and the client before the semester begins, which is reminiscent of the serial model. This activity is described in detail in Chapters 2 and 3. Then the software Development is completed by students and the client through a series of meet-task-code-test-review cycles. Each 1-2-week cycle is repeated 5 or 6 times throughout the semester, each repetition achieving a pre-determined milestone that ensures successful project completion.
  • 49. 6 ■ Client-Centered Software Development: The CO-FOSS Approach FIGURE 1.3 The CO-FOSS software development model. The Code stage relies on the fact that developers work with free and open source software (FOSS). In the FOSS world, mature well-tested code can be freely downloaded for reuse in any application with a similar functional need. Thus, developers need to read and work with code written by others. Real software is less often developed from scratch by a single individual. Instead, it is usually developed incrementally by a team, each member adding and refining parts of an existing “code base” written by others. The Test stage in each iteration of the cycle provides a new opportunity for debugging and refactoring the code base in preparation for client Review and the next iteration. Debugging means finding and correcting errors in the program. Bugs, or instances of incorrect behavior, result from programming errors. Such errors can often be notoriously difficult to find and correct, even when working with a small code base. So as an aid to finding bugs we use an aggressive strategy called “unit testing,” where individual units (classes and modules) of code are individually tested at each repetition of a CO-FOSS cycle. Refactoring a program means reading the code, finding instances of poor programming practice (from either a readability or an efficiency stand- point), and reorganizing the code so that it performs the same functions in a more readable and/or efficient way. Coding, testing, debugging, and refactoring are discussed in detail in Chapters 5, 6, and 7. Clients further test and evaluate the software during the Review stage of each cycle. They play a key part in debugging, since they are the ones who most often identify bugs and provide feedback to developers during each cycle, ensuring that the final product meets their particular expectations. A more
  • 50. The Journey ■ 7 careful treatment of the client review process and its close relationship to the Test stage appears in Chapters 5, 6, and 7. Finally, Deployment of the CO-FOSS product takes place at the end of the semester, and is coordinated between the instructor, the client, and a professional software developer. This is described in detail in Chapter 9. 1.2.4 Software Customization: A Continuum A final consideration for software developers and clients involves the alter- natives that are available in selecting/developing a software product to help improve a particular mission-critical activity within the organization. These choices form a continuum – from developing a completely customized soft- ware product to obtaining a completely off-the-shelf product, with many other choices in between. Let’s take a look at the trade-offs among three key choices in this continuum: Custom software, Off-the-shelf software, and Custom software with off-the-shelf components. Custom Software Custom software is just what its name suggests. The developer designs and im- plements a unique piece of software that can improve a client’s mission-critical activity. The software is tailored to match all that activity’s needs, processes, and security requirements. Importantly, the client’s staff can assimilate that software easily because it uses existing organizational vernacular that the staff already knows. Custom software may be open source or proprietary (see Section 1.3), but the client must rely on the developer to keep it up to date with changing organizational needs. So a strong working relationship between the developer and client is essential for custom software to remain effective. Custom open source software is ideally client-centered, allowing the client to be involved continuously in the development process. Custom software is not without its downsides. First, its original develop- ment cost can be higher than the alternatives, if there are any. Second, asking the developer to add new features as requirements change may also be bill- able. Third, custom software has no peer user community outside the client’s organization to provide advice on usability issues, though this downside is somewhat mitigated by the developer’s ongoing availability. All the software projects discussed in this book have developed custom open source products. Each one is fitted to satisfy the requirements of a sin- gle customer. For example, Homebase was originally developed in 2008 for the Ronald McDonald House in Portland, ME. Enhancements were made by differ- ent student teams in 2012 and 2013. A single developer returned in 2015 to add
  • 51. 8 ■ Client-Centered Software Development: The CO-FOSS Approach more features to Homebase. These results would not have occurred if Home- base were not open source and developed using a client-centered approach. When weighing whether to use custom software, an organization should be sure that there is no satisfactory off-the-shelf product available that can satisfy its requirements at an affordable cost. It should also find a developer that can produce that custom software and provide ongoing support, all at an affordable cost. For example, all the software products discussed in this book were developed and are supported at no cost to their clients. However, since each of these products was developed using the CO-FOSS model, it did require client participation (averaging about 2 person-hours per week) throughout its development process. Off-the-Shelf Software Off-the-shelf software is a (proprietary or open source) product developed for a large number of customers. Examples include Microsoft Word, Apache OpenOffice, Google Sheets, and various smartphone- and tablet-based com- puter games. Off-the-shelf software is aimed at addressing a specific shared need of a mass market audience, such as the need to play a game of Sudoku on a smartphone while waiting for an airplane. The per-user cost of off-the-shelf software can vary greatly; some products are free, others are costly, and still others are available as both free “intro- ductory” versions and paid “full” versions. The full versions of off-the-shelf software usually come with a preponderance of features, most of which are not needed by the average user. These features are there in order to satisfy the one-size-fits-all requirement. However, their presence can make the software more difficult to learn and use. Off-the-shelf software can be deployed quickly, usually with a simple down- load and install step. Another advantage of popular off-the-shelf software products is that they have large, often international, communities of users and forums that provide self-help support. So the user doesn’t need to hire a developer to fix a bug or customize the software to fulfill a specific need. On the downside, off-the-shelf software typically will not match all of an organization’s needs, either lacking needed features or providing superfluous features. If customization is even possible, that typically comes at an addi- tional cost. Routine upgrades may also come with additional costs. Finally, off-the-shelf software can be obsolete or slow to evolve with the industry to which it is targeted. Moreover, its vernacular is invariably out of sync with the user organization’s vernacular, requiring users to assimilate a new vocabulary before becoming comfortable with the software. Off-the-shelf software may also require technologies that do not conform to the organiza- tion’s current computing platform. Moreover, it often comes with the subtle inability for an organization to change to a different vendor in the future when a better alternative emerges (this is sometimes called “vendor lock-in”).
  • 52. The Journey ■ 9 Custom Software with Off-the-Shelf Components There is a middle ground between custom software and off-the-shelf software, which is becoming an increasingly popular solution for organizations. The idea of “custom software with off-the-shelf components” is that an organiza- tion finds software that matches most of its specific needs but requires a few additional functions in order to match the rest. Typically, this approach uses open source software at its core, though some of the add-on components can be proprietary as well. A good example is Wordpress, which is free open source software out of the box for building websites. A Wordpress website can be customized by adding “plugins” which are modules that provide specialized functionality so that the website can provide specific functionality that matches an organization’s pe- culiar requirements. The Wordpress plugin library is huge, and it covers a wide range of functionalities, such as membership management, on-line application form processing, and on-line product catalogs for e-commerce. The advantages of this approach to software development are mainly that it leverages pre-existing libraries of reliable modules to help reduce up-front costs, especially those associated with writing and testing new code. Other advantages are derived from its basic open source nature: the organization owns the software and its attendant database (avoiding vendor lock-in), the software can be continuously updated to meet changing needs, and there are no licensing fees. The disadvantages of this approach are higher upfront costs vs. off-the-shelf software and the requirement for an ongoing relationship with a developer to make changes and upgrades (which may be billable). Like custom software, this approach has no attendant user community to provide self-help (though the relationship with the developer compensates for this). 1.3 SOFTWARE LICENSING A software product can be licensed in one of two general ways, proprietary or open source. The differences between these two types of licenses are significant, especially in regard to the software development process and environment in which the software is created and maintained. 1.3.1 Proprietary Licensing Proprietary software is that which is licensed and sold as a binary executable program to individual and corporate customers. The source code is the private property of the developer and is kept hidden from the customer. A proprietary software license typically limits the number of computers on which a user can install the software – installing the software on more than one computer costs more money. So a proprietary license prevents the user from copying the software, modifying it, or sharing it freely with associates and friends.
  • 53. 10 ■ Client-Centered Software Development: The CO-FOSS Approach From the 1970s to the mid-1980s, nearly all software was developed and sold with a proprietary license. Proprietary software is developed and main- tained by an in-house programming staff of a large organization or by a vendor targeting a specific market. All developers of a proprietary software product must sign a non-disclosure agreement (known informally as an NDA) which binds them to secrecy about the product’s source code and architecture. For example, Word was developed by Microsoft’s own programmers to meet the needs of the word processing market. Today it can be bought by a single user either stand-alone (for $110) or as part of Microsoft’s “Office 365” bundle, a cloud-based subscription service that includes Word, Excel, PowerPoint, OneNote, Outlook, Publisher, Access, OneDrive, and Skype (for a $70 yearly subscription). The license for a single-user version of Word is a 30-page document “Microsoft Software License Terms,” which spells out that the user has the right to install and use a single copy of the software on a single computer, but cannot copy it to a second computer or pass it to a friend. Google Docs is a proprietary word processor that runs on a web server and is a free alternative to Microsoft Word. While Google Docs is less feature-rich than Word, many users prefer that because of its intuitive functionality and its interoperability with other aspects of cloud computing. Most importantly, Google Docs’ cloud-based functionality supports smooth simultaneous editing of a shared document by several persons. Microsoft’s cloud-based version of Word, when it is bundled within Office 365, also supports this kind of collab- oration. 1.3.2 Open Source Licensing Free and open source software (FOSS) is software whose source code and binary executable code are freely available for download by any individual or organization. Most significantly, “freely” means that downloaders are free to use the software on any computer, to modify the source code and binary, and to share the modified software with associates and friends. Because of this freedom, FOSS is accessible in markets where proprietary software has no interest and little leverage—non-profit organizations, developing countries, and individuals and businesses who are either unwilling or unable to pay the cost of purchasing proprietary software. Most proprietary software has a FOSS alternative. For example, a FOSS alternative to Microsoft Word is called “Writer” and is part of the “OpenOf- fice” bundle, maintained and distributed by the Apache Foundation. OpenOf- fice allows any individual or organization to freely download and use it on any number of computers. It runs on Windows, Linux, and Macintosh platforms. OpenOffice is distributed under an open source license called the “Apache License Version 2.0,” which describes the rights of clients to download and freely use, copy, modify, and redistribute this software. The Android operat- ing system also carries the Apache license [24].
  • 54. The Journey ■ 11 Besides the Apache License, three slightly different types of licenses are used for FOSS products: The MIT License [27] was developed by the Open Source Initiative to provide a totally unrestricted vehicle for reworking and redistributing the source code. The GNU General Public License [14], or GPL for short, was devel- oped by the GNU Foundation to provide a vehicle for reworking and redistributing the source code, but with the caveat that any redistribu- tion must be GPL-licensed FOSS as well. This caveat effectively keeps all derivatives of the product in the FOSS domain for other developers to freely use and refine. The Mozilla Public License, or MPL for short, was developed by the Mozilla Foundation for its Firefox browser and is used by many other software products today. Many popular FOSS products (Linux and Wordpress, for example) are licensed under the GPL, preventing them from ever being commercialized or embedded inside a proprietary product. Version 2 of the GPL was released in 1991. The GPL has been repeatedly upheld in courts around the world as an enforceable license [2]. Since 1991, a variety of FOSS licenses have evolved alongside the GPL to satisfy different needs within the open source commu- nity. GPL version 3 (GPLv3) was released in 2007 to address a wide range of issues, especially its compatibility with these other FOSS licenses. Unlike the GPL, neither the Apache License nor the MIT license protects a software product from having one of its derivative products converted into a proprietary product and sold for profit. For example, Apple’s MacOS op- erating system is proprietary software derived from the FOSS product BSD Unix, which carries an MIT-like (permissive) license. The LGPL and MPL represent a middle ground between the permissive MIT license and the protective GPL license. That is, while they protect the FOSS software and its derivatives from becoming fully proprietary, they allow the software to be embedded in a larger proprietary product. Today, there are dozens of different FOSS licenses. The Free Software Foun- dation’s own list of other licenses cites rulings on which ones are compatible with the GPL as well as guidance on how to define customized FOSS li- censes [15]. The Open Source Institute maintains a similar list as part of its effort to define open source software [27]. One of the most difficult questions for FOSS developers is how the vari- ous licenses relate to each other. Figure 1.4 [44] provides an overview of the more widely used licenses and their inter-relationships. Each box represents a particular kind of license. A license is more or less protective depending on how strongly it protects the freedoms listed in the FOSS definition, particularly the freedom to re- distribute derivatives of the software. The left-to-right arrangement of the
  • 55. Other documents randomly have different content
  • 56. their fellow-servants, but were attacked by superior numbers of the Canadians, and beaten off, with violence and bloodshed.
  • 57. CHAPTER XXIX. 1808-1812. Crisis in the Company's Affairs—No Dividend Paid—Petition to Lords of the Treasury—Factors Allowed a Share in the Trade—Canada Jurisdiction Act—The Killing of MacDonnell—Mowat's Ill-treatment —Lord Selkirk—His Scheme laid before the Company—A Protest by Thwaytes and others—The Project Carried—Emigrants sent out to Red River—Northmen Stirred to Reprisal. England was again at war with France. Napoleon had placed an embargo on English commerce, and to the uttermost corner of Europe was this measure felt. Tons of the most costly furs, for which there was no market, lay heaped in the Company's warehouse. The greatest difficulty was experienced in procuring servants, especially seamen, and when these were procured, they were often seized by a press-gang; shares began to decline in value; numerous partners were selling out their interests, and no strong man appeared at the head of affairs. In 1808 no dividend was paid, chiefly the result of the non- exportation of the Company's furs to the Continent of Europe. There were the accumulations of furs imported during 1806, 1807 and 1808 lying in the warehouse without prospect of sale. The pressure still continued and at last, in 1809, the Company was driven to petition the Chancellor of the Exchequer for transmission to
  • 58. The Company in difficulties. Lords of the Treasury, setting forth the Company's position and its claims on the nation. "Accumulated difficulties," it said, "have pressed hardly on the Company and we ask assistance to maintain a colony that till now has found within itself resources to withstand the pressure of all former wars and to continue those outfits on which six hundred Europeans and their families and some thousands of native Indians depend for their very existence. "We assure your worships that it was not until all those resources were exhausted that we came to the resolution of making the present application." The petition recited that after having received their charter the Company had colonized such parts of newly granted territories as appeared most convenient for carrying on their commerce with the natives. This commerce "consisted in the barter of British manufactures for the furs of animals killed by the different tribes of Indians who were within reach of factories and gradually extended itself till, as at the present moment, the manufactures of Great Britain are borne by the traders of Hudson's Bay over the face of the whole country from Lake Superior to the Athabasca. "The trade is at present pursued by the export of furs, gunpowder, shot, woollens, hardware and other articles, which together with large supplies of provisions for the factories, constitute an annual outfit consisting wholly of British manufactures and British produce of from £40,000 to £50,000, in return for which we receive the furs of bears, wolves, foxes, otters, martens, beaver and other animals, together with some oil and articles of inferior value. The cargoes are sold at public sale. The beaver and some few inferior furs, together with the oil, are bought for home consumption and sell for about £30,000, but the fine furs were, till after the sale of 1806, bought by the fur merchants for the fairs of Frankfort and of Leipsic for Petersburg, and before the present war, for France. Since that year
  • 59. there has not been a fur sold for exportation, and as a proof to your worships that the deficiency of buyers did not arise from our holding back for a higher market, we sold in 1806 for seven shillings per skin furs that in the more quiet state of Europe in 1804 had brought us 20s. 3d., and which for years previous to that time had sold for a similar price; and other depreciation pervaded in about the same proportion the whole of those furs calculated only for the foreign market, and in some instances furs were sold for a less price than the duties we had paid for them. "Since that period no orders have been received from abroad, and our warehouses are filled with the most valuable productions of three years' import that if sold at the prices of those years before the closing of the ports on the Continent would have produced us at least £150,000. "It may be objected to us, that we were improvident in pursuing under such circumstances a trade which must so inevitably tend to ruin. But a certainty that a considerable quantity of furs found their way to New York, and an earnest zeal for the preservation of trade which by the conduct of the Hudson's Bay Company had been secured to this country for a century and a half, prompted us to every exertion to maintain the footing we had established, and the annually increasing amount of our trade gave us just grounds to look forward with confidence to the opening of the northern ports of Europe as the period when all our difficulties would cease; an event which, anterior to the battles of Austerlitz or of Jena, was looked for with the most sanguine expectation. "Above all were we impelled by the strongest motives to continue these supplies which were necessary for the subsistence of six hundred European servants, their wives and children, dispersed over a vast and extended field of the North American Continent, and who would not be brought to Europe under a period of three years as well as those upon whom the many Indian nations now depend for their very existence.
  • 60. Petition of the Company. "The nations of hunters taught for one hundred and fifty years the use of fire-arms could no more resort, with certainty, to the bow or the javelin for their daily subsistence. Accustomed to the hatchet of Great Britain, they could ill adopt the rude sharpened stone to the purposes of building, and until years of misery and of famine had extirpated the present race, they could not recur to the simple arts by which they supported themselves before the introduction of British manufactures. As the outfits of the Hudson's Bay Company consist principally of articles which long habit have taught them now to consider of first necessity, if we withhold these outfits, we leave them destitute of their only means of support. The truth of this observation had a melancholy proof in the year 1782, when from the attack made upon the settlements by La Pérouse, and the consequent failure of our supplies, many of the Indians were found starved to death. "It was not only from the firm conviction that we felt of the necessity of European manufactures to the present existence of whole nations of North American Indians that we considered ourselves bound by the most powerful ties to exert every effort in their favour; but also that we might continue to them those advantages which would result to their religious as well as civil welfare from the progressive improvements, and a gradual system of civilisation and education which we have introduced throughout the country; improvements which are now diffusing the comforts of civilized life, as well as the blessings of the Christian faith to thousands of uninstructed Indians, and would in their completion, we can confidently assert, have tended to the future cultivation of lands, which from experiments we found capable of growing most of the grains of Northern Europe, and from their climate adapted to the culture of hemp and flax, and from the labour of those families who would have been induced to settle at our factories, might soon have brought to this country the produce of the boundless forests of pine that spread themselves over almost the southern parts of our possessions.
  • 61. "To realize these not visionary schemes, but sure and certain plans, founded upon the progressive civilization of the natives, were objects not to be given up without the most urgent necessity, and the hope that the ruler of the French Empire could not forever shut out our trade from Europe, induced us to resort to every means within our power to preserve the advantages resulting to ourselves and to the Indians, and to the British nation. "We have exhausted those funds which we set apart for their completion; we have pledged our credit till we feel, as honest men, that upon the present uncertainty we can pledge it no farther, and we throw ourselves upon your Worship's wisdom to afford us that temporary assistance which we cannot ask at any other hands. "Were we to resort to the early history of our settlements, we might lay the foundations of just claims upon the public to assist our present wants. We could show instances of most destructive attacks by the French upon our factories. Our forts and military works, mounted with a numerous and expensive artillery for the defence of the colony against their future operations, were destroyed and the guns ruined. And particularly was a most grievous loss occasioned to us by the predatory attack of La Pérouse about the conclusion of the American War, which caused the distress to which we have above alluded. "Against these pressures when our trade flourished we were able to hold up, and we found within ourselves those resources which defeated the enemy's views and continued to Great Britain the trade we had established. "And it is not until pressed to our last resort that we ask of your Lordships that assistance with which we may confidently hope to preserve our trade until the continent may be again opened, when we shall be delivered from those difficulties under which we are now sinking."
  • 62. Small Government assistance. The petition was signed by Wm. Mainwaring, Governor; Joseph Berens, Deputy Governor; George Hyde Wollaston, Thomas Neave, Job Mathew Raikes, Thomas Langley, John Henry Pelly, Benjamin Harrison, John Webb. In April the Adventurers petitioned the King in Council to reduce duties on furs to one-half, or trade must suffer extinction. No profit was derivable, it said, on marten, wolf, bear, wolverine and fisher- skins. To this petition the Office of Committee of Privy Council for Trade, Whitehall, replied in the following February, that the memorial of the Hudson's Bay Company contained no proposition on which the Lords of this Council could "offer any opinion to the Lords of Treasury." As their petition was denied, the Company now boldly prepared a request and asked for a loan of £60,000, and that time be extended for paying the duties on furs imported until the continental market re-opened. To this request an answer was returned, allowing twelve months storage of furs free of duty and promising drawbacks as if storage had only been for one year, but stating that there were no funds out of which a loan could be made without special authority of Parliament. It was clear that the Company was in very low water, and that some new salutary policy was demanded. By way of a beginning, barter was abolished as a basis of trade, and money payments ordered. At the same time the Adventurers stole a leaf out of the book of the North-West company, and new regulations, comprising thirty-five articles, were made in the early months of 1810, for carrying on the business in Hudson's Bay. The principle of allowing to their chief officers a considerable participation in the profits of their trade was admitted. It was found absolutely necessary to adopt some step of this sort, as nothing of such a measure could be sufficient to stem the torrent of aggression
  • 63. with which they had been assailed by the North-West company; and their absolute ruin must have ensued if some effectual means had not been taken, not only to rectify some of the abuses which had crept in under the former system, but also to rouse their officers to a more effectual resistance of the lawless violence practised against them. The total lack of jurisdiction in the Indian country, as the territory which was the scene of the operations of the fur-traders was called, permitted crime to go unpunished, and numerous representations were made in respect to the evils of this practical immunity from punishment. In Sir Alexander Mackenzie's letter of the 25th of October, 1802, he says that, in view of the improbability of the two companies amalgamating, a jurisdiction should be established as speedily as possible, to prevent the contending fur companies from abusing the power either might possess, so as to secure to each the fruits of fair, honest and industrious exertion; it would also, he believed, tend to put a stop to the increasing animosity between the two companies. Mr. Richardson, of the other company, also pressed for the establishment of a competent jurisdiction and instanced the case of one of the clerks in his company who had killed a clerk of the other in defending the property in his care. The young man had come to Montreal to be tried, but there being no jurisdiction there for such trial, "he remains in the deplorable predicament that neither his innocence nor his guilt can be legally ascertained." He also proposed that a military post should be established at Thunder Bay, on Lake Superior, as an additional means of securing peace. Repeatedly had the Grand Juries of Quebec and Montreal called attention to this want of jurisdiction. In one report the number of people from the Canadas, chiefly from Lower Canada, was urged as one reason for establishing in the Indian country a court of competent jurisdiction for the trial of offences committed in these territories, including Hudson's Bay. "The very heavy expense," observes the report, "incident to the conveyance of offenders from the Territory of Hudson's Bay to
  • 64. Plea for establishment of jurisdiction. England, with the necessary witnesses on both sides, and the cost of prosecution and defence, must generally operate, either to prevent recourse to a tribunal across the ocean, and thereby stimulate to private retaliation and revenge, or where such course can or shall be had, the guilty may escape punishment, and the innocent be sacrificed from the distance of time and place of trial, the death or absence of witnesses, or other causes; and the mind cannot contemplate without horror the possible abuses to which such circumstances might give rise; as in the instance of a prosecutor coming from and at a remote day, when the accused may be destitute of pecuniary means, and the exculpatory evidence may either be dead, removed, or be otherwise beyond his reach, who at all events (however innocent he may finally be found) will have undergone a long and painful confinement, far removed from his family and connections, and perhaps ruinous to every prospect he had in life." Sir Robert Milnes strongly supported the representation of the Grand Jury, and added that "Under such circumstances every species of offence is to be apprehended, from Trespasses to Murder," and also that "the national character of the English will be debased among the Indians, and the numerous tribes of those people will in consequence thereof be more easily wrought upon by foreign emissaries employed by the Enemies of Great Britain."[88] In consequence of these representations Lord Hobart promised that immediate steps should be taken to remedy the existing state of affairs. But Milnes became impatient for a decision, and writing in September, 1803, to the Under-Secretary, he reminded him of the promise, the great increase and extent of the fur-trade rendering such an Act daily more necessary. The Act to give jurisdiction to the Courts of Upper and Lower Canada had, however, been assented to on the 11th of the preceding month.
  • 65. Canada Jurisdiction Act. Voyageurs Tracking Canoes up a Rapid. The first case brought to trial under the Act became celebrated. In the autumn of 1809 William Corrigal was the trader at a Company's post near Eagle Lake. On the 15th of September a party of North-Westers established an encampment about forty yards from the Company's post, under one of their clerks, Aeneas MacDonnell. In the evening an Indian arrived in his canoe to trade with Corrigal and to pay a debt which he owed him. As he was not able to defray the whole amount, Corrigal accepted the canoe in part payment. The Indian requested that it might be lent to him for a few days, which was agreed to; and the Indian spent the night at the post with his canoe. In the morning he received in advance some more merchandise, such as clothing for his family and ammunition for his winter hunt. When he finally departed, three of the Company's servants were sent down to the wharf with the canoe and the goods. On their way they were observed by a number of Northmen, including MacDonnell, who went immediately down to the lake, armed with a sword and accompanied by a voyageur named Adhemer, armed with
  • 66. Killing of MacDonnell. a brace of pistols. Upon pretence that the unhappy Red man was indebted to the North-West company, they proceeded to seize and drag away the canoe and the merchandise to their own wharf. Corrigal observing this, commanded two of his men, James Tate and John Corrigal, to go into the water and prevent the seizure, and as they approached on this mission MacDonnell drew his sword and struck two blows at Tate's head. The latter was unarmed, and warded the blows with his wrist, which was severely gashed. He then received another deep wound in the neck, which felled him to the ground. In the meantime Adhemer had seized John Corrigal (who was also unarmed) and presenting a cocked pistol at his head, swore that if he went near the canoe he would blow out his brains. Several of the Company's servants who were near the spot, perceiving what was going on, and observing that the rest of MacDonnell's men were collecting with arms, ran up to their own house, which was only about forty or fifty yards from the lake, for weapons of defence. MacDonnell next attacked John Corrigal, who to escape him ran into the lake. Finding the water too deep, however, he was soon obliged to make a turn towards the shore. His pursuer wading after him, aimed a blow at him with his sword, cut his arm above the elbow and laid the bone bare. He followed this up with a tremendous blow at his head, which Robert Leask, one of the Company's servants, fortunately warded off with the paddle of his canoe, which was cut in two by the blow. The North-West leader in a fury now attacked another servant named Essen, aimed a blow at him with his sword, which, however, only struck his hat off. But in making his escape Essen fell into the water. Before he could recover himself another Canadian aimed a blow at his head with a heavy axe, which missed its aim, but dislocated his shoulder, so that he could make no use of his arm for over two months after this affray. MacDonnell and Adhemer, the one with a drawn sword and the other with a cocked pistol, continued to pursue several other of the Company's servants towards the fort, when one of them, named
  • 67. Trial of Mowat. John Mowat, whom MacDonnell had previously struck with his sword, and was preparing to strike again, shot MacDonnell on the spot. MacDonnell's body was carried away, and the parties separated, Corrigal fearing a further attack. On the 24th, a partner of the North-West Company, named Haldane, arrived in a canoe with ten men, and on the following day another partner, McLellan, also arrived. They came to the gates of the stockades, behind which Corrigal and his men had barricaded themselves, and demanded the man who had shot MacDonnell. They declared that if the person was not immediately given up they would either shoot every one of the Company's men, or get the Indians to kill them, were it even to cost them a keg of brandy for each of their heads! Mowat now stepped forward and acknowledged that he was the man, and that he would shoot MacDonnell again in the same circumstances. Much to his surprise the North-Westers announced their intention of taking him and two witnesses down to Montreal for trial. Mowat was thereupon put in irons. From the 2nd of October, when they arrived at Rainy Lake, the unhappy man was generally kept in irons from six in the morning till eight in the evening, and during the night until the 14th of December. During the whole winter he was kept in close confinement, and the two witnesses, Tate and Leask, who had voluntarily accompanied him, were themselves subjected to much insult and indignity, and were obliged to submit to every species of drudgery and labour in order to obtain a bare subsistence. In June the whole party, including Corrigal, arrived at Fort William, the chief trading-post rendezvous of the North-Westers. Here Mowat was imprisoned in a close and miserable dungeon, about six feet square, without any window or light of any kind whatsoever, and when he finally reached Montreal he was in a most pitiable condition. The witnesses were seized on a charge of aiding and abetting the murder of MacDonnell, and this upon the oath of one of the North-West half- breeds. The Hudson's Bay Company had at this time no agent or correspondent at Montreal or any place in Canada, and it was not
  • 68. The Earl of Selkirk. until the end of November that the Honourable Adventurers heard of the prosecution being carried on against their servants. Immediate steps were taken for their protection, and counsel engaged for the defence. Mowat and his witnesses were indicted for murder. The grand jury found a true bill against Mowat, but not against the others, and Tate and Leask were accordingly discharged.[89] In spite of the evidence, the jury brought in a verdict of manslaughter. The judge, however, had charged them to find it murder. Mowat was sentenced to be imprisoned six months and branded on the hand with a hot iron. After his discharge, two years from the time he was first put in irons at Eagle Lake, Mowat proceeded from Canada to the United States in order to return to England, but was never heard of again. He is supposed to have been drowned by the breaking of the ice in one of the rivers he had to cross on his way. Such was the situation in the early years of the century. At this time there rose a name destined to be of more than local fame, that of Thomas Douglas, fifth Earl of Selkirk, a young man of benevolent character, whose feelings had been deeply moved by the sufferings of his countrymen in the Scottish Highlands. Nor was the nobleman's compassion excited without cause. A compulsory exodus of the inhabitants of the mountainous regions in the county of Sutherland was in progress. The tale of expulsion of a vast number of poor tenantry from the estates of the Duchess of Sutherland, which they and their ancestors had looked upon as their own without the necessity of rent and taxes, may be heard to-day from some white- haired old grandfather, who had it from the lips of his sire, in the far north of Scotland. The system of rents and land-management as it prevails to-day all over the Highlands had only then been put in force, and the squatters were driven to seek their homes as best they might in the remote and sequestered places of the earth. Selkirk encouraged this emigration as the only remedy; and having endeavoured in vain to secure the active co-operation of the
  • 69. Government, resolved to settle a colony on waste lands granted him in Prince Edward Island. The better to ensure success, he went in person to oversee the whole enterprise. Gathering together about eight hundred of these poor people, who bade a melancholy farewell to their heather-robed hills, they arrived at their future home early in September, 1803. Lord Selkirk. Selkirk visited Montreal in this and also in the following year on matters connected with his philanthropic undertaking, and on both occasions evinced the heartiest interest in the great territory to the north-west which formed the theatre of action for the two rival fur- trading companies. The Prince Edward Island colony continuing to prosper, Lord Selkirk now conceived the plan of forming a colony on the banks of the Red River, in Rupert's Land.[90] In order to execute his project with a greater assurance of success, he again, in 1805, addressed the
  • 70. Legal opinion on the Company's charter. British Government and nation, pointing out the successful issue of his colony as an example of the excellent results which would attend a further exodus of the superfluous population. Time went on and the execution of the plan being still in abeyance, the great decline in Hudson's Bay stock suggested an idea to Selkirk. He submitted the charter to several of the highest legal authorities in England, and got from them the following: "We are of the opinion that the grant of the said contained charter is good, and that it will include all the country, the waters of which run into Hudson's Bay, as ascertained by geographical observations. "We are of opinion that an individual holding from the Hudson's Bay Company a lease or grant in fee simple of any part of their territory, will be entitled to all the ordinary rights of landed property in England, and will be entitled to prevent other persons from occupying any part of the lands; from cutting down timber and fishing in the adjoining waters (being such as a private right of fishing may subsist in), and may (if he can peaceably or otherwise in due course of law) dispossess them of any buildings which they have recently erected within the limits of their property. "We are of opinion that the grant of the civil and criminal jurisdiction is valid, though it is not granted to the Company, but to the Governor and Council at their respective establishments. We cannot recommend, however, it to be exercised so as to affect the lives or limbs of criminals. It is to be exercised by the Governor and Council as judges, who are to proceed according to the laws of England. "The Company may appoint a sheriff to execute judgments and do his duty as in England. "We are of opinion that the sheriff, in case of resistance to his authority, may collect the population to his assistance, and put arms into the hands of his servants for defence against attack, and to
  • 71. assist in enforcing the judgments of the courts; but such powers cannot be exercised with too much circumspection. "We are of opinion that all persons will be subject to the jurisdiction of the court, who reside or are found within the territories over which it extends. "We do not think the Canada Jurisdiction Act (43 George III.) gives jurisdiction within the territories of the Hudson's Bay Company, the same being within the jurisdiction of their own governors and council.[91] "We are of opinion that the Governor (in Hudson's) might under the authority of the Company, appoint constables and other officers for the preservation of the peace and that the officers so appointed would have the same duties and privileges as the same officers in England, so far as these duties and privileges may be applicable to their situation in the territories of the Company." This was signed by Sir Samuel Ronully, Mr. Justice Holroyd, W. M. Cruise, J. Scarlett and John Bell. There could be thus no question of Selkirk's right. The Company's charter, amongst other provisions, expressly forbids all English subjects from entering, without license or authority, upon the territories of the Hudson's Bay Company. The Governor and Company only are empowered to grant such authority and on them also is conferred the right of establishing castles, fortifications, forts, garrisons, colonies, plantations, towns and villages, in any parts or places within the limits of their territory. They had also the right of sending ships of war, men or ammunition, to their colonies, fortifications or plantations, and of appointing governors, commanders and officers over them. Selkirk began by purchasing several thousand pounds worth of shares in the Company. Late in 1810 he made a formal proposition to the Company, a proposition previously made and rejected, for a settlement to be made within its territory. This time some of the Honourable
  • 72. Selkirk's project. Adventurers began to see that the scheme might be fraught with salvation for themselves. Lord Selkirk was asked to lay before the committee the terms on which he would accept a grant of land within the Hudson's Bay territories, "specifying what restrictions he would be prepared to consent to be imposed on the settlers." Also what security he would offer to the Company against any injury to its trade or to its rights and privileges. Lord Selkirk responded to this, and his proposals were agreed to, subject to final approbation of a general court of all the Adventurers. It now dawned upon the wiser spirits that here was being offered them the means for the Company's salvation. Nevertheless, the traditional opposition of the Company to any project of the kind still lingered, and was not easily disposed of. For weeks the meetings in committee resounded with appeals to "traditional policy," to "loyalty to the noble, the ancient founders," to "a spirit of reverence for the history of our Company," but all to no purpose. Selkirk was to carry the day. A general court was convened, by public notice, in May 1811, when the stockholders were informed that the Governor and Committee considered it beneficial to their general interests to grant Lord Selkirk 116,000 square miles of their territory, on condition that he should establish a colony and furnish, on certain terms, from amongst the settlers, such labourers as would be required by the Company in their trade. In order to give the partners a further opportunity of making themselves fully informed of the nature of the proposed measure, an adjournment of the court took place. In the meanwhile notice was given to all the stockholders that the terms of the proposed grant were left at the secretary's office for their inspection. This interval was the opportunity of McGillivray and his friends.
  • 73. Opposition by agents of the North- West Company. In certain quarters, no pains or misrepresentations were spared by persons associated with the North-West Company to prejudice the public mind against it. The newspapers teemed with falsehoods representing the country as cold or barren, as a dreary waste or interminable forest, unfit to be the abode of men and incapable of improvement. Selkirk was accosted in Pall Mall by a friend who remarked: "By God, sir, if you are bent on doing something futile, why do you not sow tares at home in order to reap wheat, or plough the desert of Sahara, which is nearer." Old servants of the Company came forward to dispel these calumnies, and seeing their first falsehoods destroyed, Selkirk's enemies now proceeded to follow new tactics. They spoke with feigned alarm concerning the hostile disposition of the aborigines; they lamented with affected sympathy and humanity the injuries and slaughters to which the colonists would be exposed from the savages. At the adjourned meeting the proposition was again discussed amidst the greatest excitement and tumult, and adopted. A memorial or protest was however entered against the measure, bearing the signature of six of the proprietors. Of these six signing the protest, three were persons closely connected with and interested in the rival commercial concerns of the North-West Company of Montreal; and two of the three were, at the very moment, avowed London agents of that association. These had become proprietors of Hudson's Bay stock only eight and forty hours before the general meeting. They were not indeed possessed of it long enough to entitle them to vote at the meeting; but their names now being entered in the Company's books, though the ink was scarcely dry with which they were inserted, they felt themselves competent to formally raise their voices in condemnation of those measures which the committee of directors unanimously, and the general court by a great majority, had approved of.
  • 74. Their design in acquiring the Company's stock was obvious. However circuitous the stratagem might be, it was clear that they had thus become proprietors of one commercial company for the purpose of advancing the fortunes of another, and a rival concern.[92] The stratagem did not altogether fail, for Lord Selkirk's agents were yet to encounter much friction in distant quarters supposed to be friendly, and required to be obedient to the orders of the Company. When the vote was taken, it was found that for the question there appeared holders of stock valued at £29,937; against it, £14,823. The Earl, himself, voted "for"—£4,087; the principal opponent of the scheme being one William Thwaytes, whose interest was represented at £9,233. At this meeting a memorial was read violently opposing the scheme, signed by Thwaytes and four or five others. According to them, the main objections were:—(a) Impolitic; (b) Consideration inadequate; (c) Grant asked for very large proportion of Company's holding, viz.: 70,000 square miles, or about 45,000,000 acres; (d) Should be a public sale, if any, not a private contract with a member of the Company; (e) No penalty for failure to find settlers; (f) Colonization unfavourable to the fur-trade; private traffic would be carried on with the United States of America. The Earl proposed to find a number of effective men as servants to the Hudson's Bay Company in return for a grant of land, viz., two hundred men for ten years, from 1812, who would every year be ready to embark between May 1st and July 1st at an appointed place in Scotland. The Company were to pay wages to each man not exceeding £20. Should the Earl fail, he agreed to forfeit £10 per man short of two hundred. As to proposed grants of land to settlers, two hundred acres were to be given to labourers or artificers; one thousand acres to a master of a trading-house. The Company were, of course, to have full rights of access to all the surrendered districts.
  • 75. Earl Selkirk's proposal accepted. The customs duties, exports and imports, payable by settlers were not to exceed five per cent, at Port Nelson, unless it happened that a higher duty was levied at Quebec. The duties so to be levied were to be applied to the expense of Government police, communication between Lake Winnipeg and Port Nelson, etc., and not to be taken as profits for the Company. The show of hands was in favour of the proposal; but a protest was handed in to the Governor by Thwaytes and others. In spite of this, on the 13th of June, the deed was signed, sealed and delivered by the secretary on behalf of the Company. The lands were defined by deed as situate between 52° 30' north latitude and 102° 30' west longitude, a map being affixed to the deed. In reading this protest, one who was ignorant of the true state of affairs would have been led to believe that the partners concerned had no object so dear to them as the welfare and prosperity of the Hudson's Bay Company. These gentlemen appeared to be animated by the most thorough devotion and zeal, as they stood together declaiming in loud, earnest tones against the errors into which their beloved Company was falling, and pouring out their sympathy to the emigrant settlers who might be lured to their destruction by establishing themselves on the lands so granted "out of reach," to employ their own phrase, "of all those aids and comforts which are derived from civil society;" and so it did truly appear to many then as it has done since. But let us examine those signatures, and lo, the wolf obtrudes himself basking in the skin of a lamb! The grant was thus confirmed. The opposition had found itself powerless, and Selkirk was put into possession of a territory only 5,115 square miles less than the entire area of the United Kingdom of Great Britain and Ireland.[93] The grant secured, Selkirk at once despatched agents to Ireland and throughout the highlands of Scotland, to engage servants, some for the Company's service, others for general labourers in the colony.
  • 76. Selkirk's immigrants arrive. These last were known as "his lordship's servants," and were engaged for a term of years, at the expiration of which they became entitled to one hundred acres of land, free of cost. They were placed under the charge of Miles McDonnell, who received a joint appointment from Selkirk and the Company, as first Governor of the new colony. The first section of the immigrant party arrived at York Factory late in the autumn of 1811.[94] This post was then in charge of William Auld, who, as we have seen, occupied the position of Superintendent of the Northern Department of Rupert's Land. After a short residence at the fort, where they were treated in a somewhat tyrannical and high- handed fashion by the Governor, who had scant sympathy for the new régime, the party were sent forward to Seal Creek, fifty miles up Nelson River. Governor McDonnell and one Hillier, in the character of justice of the peace, accompanied them thither, and preparations were at once made for the erection of a suitable shelter. Stornaway. (The Hebrides.) McDonnell experienced a great deal of trouble during the winter with the men under his charge, for a mutinous spirit broke out, and he was put to his wits' end to enforce discipline. He put it all down to
  • 77. the Glasgow servants. "These Glasgow rascals," he declared to Auld, the Governor of York Factory, "have caused us both much trouble and uneasiness. A more stubborn, litigious and cross-grained lot were never put under any person's care. I cannot think that any liberality of rum or rations could have availed to stop their dissatisfaction. Army and navy discipline is the only thing fit to manage such fierce spirits." But the Irish of the party were hardly more tractable. On New Year's night, 1812, a violent and unprovoked attack was made by some of the Irish on a party of Orkneymen, who were celebrating the occasion. Three of the latter were so severely beaten that for a month the surgeon could not report their lives entirely out of danger. Four of the Irishmen concerned in this assault were sent back home. "Worthless blackguards," records the Governor; "the lash may make them serviceable to the Government in the army or navy, but they will never do for us." On the subject of the Orkney servants of the Company all critics were not agreed. Governor McDonnell's opinion, for instance, was not flattering:— "There cannot," he reported, "be much improvement made in the country while the Orkneymen form the majority of labourers; they are lazy, spiritless, and ill-disposed—wedded to old habits, strongly prejudiced against any change, however beneficial. It was with the utmost reluctance they could be prevailed on to drink the spruce juice to save themselves from the scurvy; they think nothing of the scurvy, as they are then idle, and their wages run on.... It is not uncommon for an Orkneyman to consume six pounds or eight pounds of meat in a day, and some have ate as much in a single meal. This gluttonous appetite, they say, is occasioned by the cold. I entirely discredit the assertion, as I think it rather to be natural to themselves. All the labour I have seen these men do would scarcely pay for the victuals they consume. With twenty-five men belonging
  • 78. Opposition by the Nor'-Westers. to it, the factory was last winter distressed for firewood, and the people sent to tent in the woods."[95] Meanwhile, leaving the shivering immigrants, distrustful of their officers and doubtful of what the future had in store for them, to encamp at Seal Creek, let us turn to the state of affairs amongst the parties concerned elsewhere, particularly amongst the Nor'-Westers. Simon McGillivray, who was agent in London for that Company, watched all Selkirk's acts with the utmost distrust, and kept the partners continually informed of the turn affairs were taking. He assured them that Selkirk's philanthropy was all a cloak, designed to cover up a scheme for the total extinction of the Hudson's Bay Company's rivals. The colony was to be planted to ruin their trade. It was an endeavour to check the physical superiority of the Nor'-Westers and by means of this settlement secure to the Hudson's Bay Company and to himself, not only the extensive and sole trade of the country within their own territories, but a "safe and convenient stepping- stone for monopolizing all the fur-trade of the Far West." The partners in Montreal were stirred to action. Regarding Lord Selkirk's motives in this light, they warmly disputed the validity of the Hudson's Bay Company's Charter and of the grants of land made to him. It was decided to bring all the forces of opposition they possessed to bear on this "invasion of their hunting grounds."
  • 79. The Bois-Brulés. CHAPTER XXX. 1812-1815. The Bois-Brulés—Simon McGillivray's Letter—Frightening the Settlers —A second Brigade—Governor McDonnell's Manifesto—Defection of Northmen to the Company—Robertson's Expedition to Athabasca—Affairs at Red River—Cameron and McDonell in uniform—Cuthbert Grant—Miles McDonnell arrested—Fort William —News brought to the Northmen—Their confiscated account- books—War of 1812 concluded. There had lately been witnessed the rapid growth of a new class—sprung from the loins of Red man and European. Alert, rugged, turbulent, they evinced at the same time a passionate love of the life and manners of the wilderness, and a fierce intractability which could hardly fail to cause occasional uneasiness in the minds of their masters. To this class had been given the name of Métis, or Bois-Brulés. They were principally the descendants of the French voyageurs of the North- West concern, who had allied themselves with Indian women and settled down on the shore of some lake or stream in the interior. Amongst these half-breeds hunters and trappers came, and at a later period a number of Englishmen and Scotchmen, hardly less strongly linked to a wild, hardy life than themselves. These also took Indian wives, and they and their children spoke of themselves as
  • 80. neither English, Scotch, or Indian, but as belonging to the "New Nation." From 1812 to 1821 the North-West concern absorbed all the labours and exacted the loyalty of the increasing class of Bois-Brulés. The Hudson's Bay Company was exclusively an English company, and their Scotch and English servants had left few traces of an alliance with the aborigines. As the posts in the interior began to multiply, and the men were thus cut off from the larger society which obtained at York, Cumberland and Moose factories, and were thrown more upon their own resources, a laxer discipline prevailed, and the example of their neighbours was followed. A time was to come when the "Orkney half-breeds" equalled in point of numbers those of the French Bois-Brulés.
  • 81. A Bois-Brulé. There were yet few half-breeds of English extraction. The Bois- Brulés were passionately attached to the North-West company, who were quick to recognize their value as agents amongst the Indians. The idea of nationality, so far from being frowned upon, was encouraged amongst them. So much for the instruments which the Company proposed to employ in Montreal. It was only natural that amongst this rude race there should arise a leader, a half-breed to whose superior ability and natural advantages was added an education in Montreal, the seat of the co-partnery. Cuthbert Grant, which was the name this individual bore, was known
  • 82. Defections from the North-West Company. far and wide amongst the hunters and trappers of Rupert's Land, and everywhere commanded homage and respect. He had risen to be one of the most enterprising and valued agents of the Nor'- Westers, and was constantly admitted to their councils. On the 22nd of May, 1811, at which period the matter was in embryo in London, Simon McGillivray had frankly declared to Miles McDonnell, agent to Lord Selkirk, that he was "determined to give all the opposition in his power, whatever might be the consequences," because, in his opinion, "such a settlement struck at the root of the North-West company, which it was intended to ruin."[96] By way of argument, this gentleman took it upon himself to inform the Hudson's Bay Company that the proposed settlement was foredoomed to destruction, inasmuch as it "must at all times lie at the mercy of the Indians," who would not be bound by treaties, and that "one North-West Company's interpreter would be able at any time to set the Indians against the settlers and destroy them." Selkirk was now informed that there were several clerks who had been many years in the service of the Northmen, and who were disaffected in that service. They grumbled at not having been sooner promoted to the proprietary—that the claims of the old and faithful were too often passed over for those of younger men of little experience, because they were related to the partners. The Earl was not slow to avail himself of this advantage. It became a matter of importance to persuade as many as possible of these dissatisfied spirits to join his scheme, by the offer of large salaries, and several accepted his offer with alacrity. Amongst the most enterprising was one Colin Robertson, a trader who had often ventured his life amongst the tribes and half-breeds, to forward the interests of his establishment. He possessed a perfect knowledge of the interior and of the fur-trade, and to him Lord Selkirk entrusted the chief management of the latter for the Company. Robertson was well convinced of the superiority of the Canadian voyageurs over the
  • 83. Orkneymen, in the management of canoes, for example, and he proceeded to engage a number of them in Montreal at a much higher wage than they had received hitherto. To Robertson's counsels must be ascribed much of the invigoration which now began to mark the policy of the Company. His letters to the Company were full of a common-sense and a fighting spirit. "Let us carry the trade to Athabasca," he said; and he proceeded to demonstrate how all rivalry could be annihilated. The strength and weakness of his rivals were familiar to him, and he was well aware how much depended on the Indians themselves. They could and would deal with whom they chose; Robertson determined they should deal henceforth, not with the North-West, but with the Hudson's Bay Company. The Northmen had been for years continually pressing to the West. They were doing a thriving trade on the Columbia River, in Oregon, where they had a lucrative post; they had a post to the south of that in California, and to the north as far as New Archangel. In the second decade of the century the North-West Association had over three hundred Canadians in its employ on the Pacific slope, sending three or four ships annually to London by way of Cape Horn. In 1810 they had a competitor in the post of Astoria, founded by John Jacob Astor, a fur-monopolist of New York. Astor had made overtures to the North-West partners, which had been declined; whereupon he induced about twenty Canadians to leave them and enter his service. He despatched two expeditions, one overland and the other by sea, around Cape Horn. But the founder of Astoria had not foreseen that the breaking out of war between Great Britain and America would upset all his plans. Fort Astoria, in the fortunes of war, changed hands and became Fort George; and although the post was, by the Treaty of Ghent, restored, the Canadians and Scotchmen had returned to their old employers and interests. In a few years the Hudson's Bay Company was to control the chief part of the fur-trade of the Pacific Coast.
  • 84. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com