Civic OS: Open Source software to empower open governance

Executive Summary

We live in a time of unprecedented access to information. Ushering in the information age has provided the ability to access vast amounts of data around decisions and measurements. At the same time, the organizations who govern us may be evolving too slowly to take advantage of this access to information. Although excellent initiatives exist, such as the Open Government Partnership, most governing organizations (governments, non-profits, etc.) have not adopted the kind of open mindset that allows for: 

  • A high degree of accountability for leadership
  • Truly interactive governance

Civic OS, as designed, will be an open source “operating system” for governance organizations. This is analogous to Enterprise Resource Planning (ERP) systems that many corporations use to manage their resources, but adapted to the needs of government and built around the principles of open data. This extensible system, developed in the open-source, will act as a platform for all city operations, while also granting transparent access to citizens, researchers, and tool builders to collaborate in government and hold elected leaders accountable.


The need for Civic OS stretches across four different categories: increased transparency around decision-making, accountable representation, cost of reporting, and increased efficiency of municipal operations.

Increased transparency around decision-making

Government corruption, thought to be a 20th-century problem, has followed us well into the 21st century despite having access to the tools to eliminate it. While citizens have the opportunity (using Freedom of Information requests) to peek into the decisions made on their behalf, this system leaves much to be desired in terms of access to information as well as cooperation. Today, we should not have to wonder if a decision made by an elected official was made to benefit the governed or only that official (and their less-than-transparent network).

Two specific areas immediately come to mind: purchasing decisions and staffing decisions. Conflicts of interest often arise in these areas as they represent large budgetary allotments, but the values weighed in these decisions are seldom publicized. If the values and rationale that led to a final decision were readily-available, governments would be more readily trusted.

Accountable representation

Citizens in a democracy are familiar with the phenomenon of the “forgotten” campaign promise. It seems as though officials on the campaign trail are content to say whatever will get them elected, regardless of the feasibility or intent to implement those ideas. It can be difficult to track the stated intention of a campaigning official throughout his or her term to discern whether they have worked to fulfill their stated intention.

Journalists do work hard to hold elected officials accountable, but this is still a large effort, relying on the work of entire teams of people. These efforts and results should be readily and easily communicated by that elected official.

Cost of reporting

In order to effectively communicate decisions, results, and other information between governing organizations and the public, a significant amount of effort is often expended in preparation of reports (financial, news and otherwise). This is a crucial function of government, but often the cost of reporting is a barrier to the open communication of information. This can leave the public wondering if an administration is opposed to openness or simply resource-strapped.

Increased efficiency of municipal operations

Governments, being complex organizations, often struggle to effectively collaborate within government let alone with members of the public. There are numerous causes for this difficulty, but many can be attributed to the effort needed to work across disparate systems (and sometimes disparate groups). In order to become more effective in governing the public, these organizations should become more effective with internal communication.


In order to address the stated needs, Civic OS is designed upon the following philosophies.

Open Government

Transparency and accountability are foundational to successful democratic governance. In order for citizens to be informed, they must have ready access to information to make good decisions about who to support, and how to vote in elections and on referenda. 

In Civic OS, accountability is achieved by enforcing the justification of decisions; in other words, forcing leaders to justify key decisions. In order for an individual to decide if he supports an action, he must be able to understand the rationale behind that decision.

See the Open Government Partnership ( for more information about Open Government.

Open Data

All data is not created equal. In order to make data open and usable the Open Data Charter has published 6 key principles (

  1. Open By Default
  2. Timely and Comprehensive
  3. Accessible and Usable
  4. Comparable and Interoperable
  5. For Improved Governance & Citizen Engagement
  6. For Inclusive Development and Innovation

Open Source

The term “open source” can have a number of meanings but Civic OS uses the definition consistent with “free software” according to the Free Software Foundation ( 

The two primary outcomes of this philosophy are democratic development and lower cost of entry. Democratic development allows entities to contribute to development (in code, financial, and administrative contributions) to influence the system’s evolution. This results in a system that is useful for a broad range of diverse organizations. Lower cost of entry is realized by the $0 licensing fees inherent in Free/Open Source software. When development is performed in the open, the cost is shared by an entire community.


This section describes the broad principles at work in the software architecture of Civic OS.

Extensible Core

The architecture of Civic OS is designed as a strong core with plugins that add real functionality. This core consists of a GraphQL API, an event-processing system, and a permissions management system. This security-hardened core allows for plugins to define various data schema and events allowing external access to their information as well as providing for internal consumption of data to other plug-ins. 

A fundamental concept of this core is permission management; each user of the system has read or write access to varying levels of data. This allows for anonymized data to be publicly accessed, but also for authenticated users from internal departments access to read and write to different parts of one system.

Inspiration for the system architecture is drawn from Odoo (formerly OpenERP) in both its openness as well as its modularity. 


A visible benefit to broadly-deployed Open Source systems (Linux, for example, which runs 95%+ of the public internet) is better security. This is achieved by exposing the software source code to the minds/eyes of a large number of developers; more software/security bugs are identified and resolved.


Another foundational concept in Civic OS is the software’s plugin system. While the Core provides a platform for data storage and recall, plugins are responsible for providing a variety of user interfaces. Plugins define a data model (which is implemented by the core) as well as user interface components, and settings. Plugins are designed to be installable and are hosted on/served by the Core rather than exist as separate software executables.

In addition to the ability to query the core for data, plugins may define code that executes in response to events. These events may trigger on time intervals or as a result of mutated data in order to allow for asynchronous processing of data.

By way of example, anticipated plugins will provide consensus/voting, polling, resource management, human resource functions, timesheets, task tracking, and meeting scheduling/input.

Workflow Plugins

In order to provide decision-based accountability, we anticipate the most crucial plugins to be based on the concept of a process workflow. With this plug-in element, a series of decisions can be defined, each with its own justification, and tracked to allow insight into who made a decision and why that path was chosen. 

In the example of a sidewalk repair complaint, a customer (citizen) could track the status of his complaint and know transparently which action was taken (or why action was not taken). Similarly, when a government procures products and services, workflows will show the crucial aspects of vendor bids as well as the qualitative and quantitative reasoning behind the ultimate decision.

Development roadmap

Minimally Viable Product

To begin delivering value with the smallest possible cost, the development of Civic OS will follow the Minimally Viable Product (MVP) mindset. We anticipate that a combination of the Core with a City Council management plugin will immediately deliver value (Accountability, Cost, Efficiency) to our first partners.

City Council management plugin

The City Council management plugin would facilitate the creation of agendas, council vote recording, and publication of meeting minutes. In addition to allowing easy, historical access to past actions, this system would act as an authoritative source for council actions for reference by city employees and residents alike.

We anticipate 3 levels of data/application access in this plugin: Clerk, Council Member, and Anonymous. Clerks and Council Members would be required to log in to authenticate their identities.

A clerk would have permission to create and publish an agenda, take attendance, and to enter meeting minutes; a Council Member would have permission to submit agenda items for consideration and to vote on proposals. All users (authenticated and anonymous) would have permission to view agendas, attendance, and proposal results.

Additional modules

Once the MVP has been completed, additional plugins may be developed in order to extend the utility of the system. Given enough time and investment to further develop a stable of plugins, Civic OS can transparently manage all of an organization’s operations.

Here are some examples of potential plugins:

  • Financial Accounting
  • Community Safety (incl. Blight)
  • Utility Billing
  • Property Tax Accounting
  • Communications (press releases, published reports, blog posts, etc.)
  • Environmental Monitoring
  • Crowdsourcing Public Sentiment

Legal Structure

The Civic OS software is designed to maximize civic benefit, which should direct the legal structure of the supporting organization. This organization has not yet been formed, but we believe that a non-profit or Public Benefit Corp. will provide the best opportunities to mature and spread the use of Civic OS.

Outstanding Questions/Areas of Research

  1. What type of interaction or data record produces the most accountable system?
  2. What conflicts (between governments and citizens) can be best resolved through this sort of tool?
  3. Will this openness act as a deterrent to internal transparency?
  4. What level of openness is hurtful to citizens?
  5. What kind of tools are needed to help citizens access information more effectively? What impact will these tools have on the “Digital Divide”?

Author’s Biography

Dan Kurin is the CEO of Swiftlet Technology and the founder of the Flint Smart City Initiative. He has co-planned two TEDxFlint events in 2010 and 2011, helped start a makerspace in downtown Flint (Factory Two), and has co-taught a DIY-focused after-school program on the north-side of Flint.

Through Swiftlet, Dan pairs technical experience from a broad range of backgrounds with an ability to facilitate diverse groups in order to solve problems for institutional and startup partners alike. He loves to learn as he engages with projects that span multiple disciplines including Electronics, Software (in all different environments), and Information Technology.

Twitter: @dantheman2865LinkedIn:

Featured Client: Generous City

As a company, we are focused on providing our clients an incredible value. One approach which helps us maximize customer value takes advantage of a recently matured trend in software development: Open Source Software. I would like to share an example of how we were able to build a custom software solution for a client using this approach.

About the company

Generous City Street Cafe is a new concept for a food truck which allows its customers to pay what they want for the food they receive. A well-off customer may pay a larger amount while a cash-strapped customer may give themselves a discount. In addition to operating as an independent food vendor, Generous City can operate as a fundraiser in which additional profits are donated to the host organization.

About the project

While researching Point-of-sale systems, Generous City found that none of the existing off-the-shelf solutions supported this unique set of requirements. Unfortunately, building a custom point-of-sale system with all of the inventory and reporting features Generous City needed would have broken the bank.

Swiftlet’s approach to this project was to identify an open-source software package which already provided a basic set of Point of sale features (menus, pricing, credit card handling, etc.) and extend that package to include the special behavior that Generous City needed. Eventually, we chose Odoo (formerly OpenERP) as the software is available with open licensing and has a modular architecture. This architecture allows an install to run lean as only the necessary plugins are installed, but it also allows for custom plugins to extend the behavior.

Customer Interaction

Allow me to walk you through how the software is used (by both parties):

  1. The Vendor builds an order by touching the items the customer requests
  2. The Vendor presses a button which loads a customer-oriented screen
  3. The Customer is presented a slider bar which is pre-loaded to the suggested price. As the Customer alters the price, a graphic shows what will be donated based on their generosity.
  4. The Customer presses “Pay” and they are shown a “Thank you” screen
  5. The Vendor closes the custom screen, prints a meal ticket, takes payment, and prints a receipt for the Customer.

The software operates as any industry-standard Point-of-sale system would until the custom behavior is invoked. Not only does this keep things simple for the user, it also allows Swiftlet to keep our modifications (and effort) minimal.


The project took place over the course of about 10 weeks and both Swiftlet Technology and Generous City were satisfied with the outcome:

  • From the client’s perspective, the software did exactly what it needed to do and was immediately used to generate revenue
  • From Swiftlet’s perspective, it was an interesting project which gave us an opportunity to explore Odoo’s capabilities

If you’re interested in starting a custom software project, contact us to get a quotation; we’ll be happy to help you formulate a plan to reach your business goals!

Featured Client: Drēm Trigger

We recently had a chance to work with an innovative, new company called Drēm Trigger. I thought the project was a good example of the breadth of our capabilities, so I wanted to share some of the details with you.

About the company

Drēm Trigger (say “Dream Trigger”) is a startup company with a new approach to drum triggering. Their goal is to make Hybrid Drumming more affordable and simpler in order to expand the range of sounds available to a drummer who may not have the budget for a large number of drums. The basic concept of a drum trigger is that the drummer attaches some instrumentation to the drum which can sense when the drum is struck and then record and/or transform the sound. One example of this would be a drummer for a band who covers a lot of other bands’ music; outfitting their drum kit with drum triggers would allow them to completely transform the sound of their kit from song to song.

About the project

Drēm Trigger was referred to me at the end of their prototype phase with an electronic prototype in-hand. They had commissioned a product prototype firm to prove the concept, so they already had a device that worked fairly well, but they needed some improvements made before launching their crowdfunding campaign.

Our task was to test a different kind of sensor with the existing electronics. This required some additional circuitry to be designed as well as some signal processing software to run on their microprocessor. After testing out a couple of different hardware designs, we identified one that would give the response time that we needed and proceeded to design software algorithms which would reliably detect each drum hit. Finally, we fused our algorithms into the existing sensor’s algorithms and, with a little bit of tweaking, we had a fully-functional prototype.


The project took place over the course of about 5 weeks and both Swiftlet Technology and Drēm Trigger were satisfied with the outcome:

  • From the client’s perspective, the device’s performance was improved to the point where it could be used the company’s crowdfunding video
  • From Swiftlet’s perspective, it was an exciting project with many interesting challenges along the way
  • Both parties agree that this is a business relationship where Swiftlet Technology was able to continually provide value to Drēm Trigger; from circuit design and testing, to algorithm design and implementation

For more information about Drēm Trigger, please visit their website at

Validated Learning

In his book, The Lean Startup, Eric Ries discusses (among other things) a way to measure early success in a startup company: Validated Learning. This is the idea that a startup company is really just a series of experiments in a new way of doing business and that, rather than measuring success in dollars earned, success should be measured in amount learned. Rather than just some lame excuse (“Well… we learned a lot!”), Validated Learning is the engine of success which drives a company forward.

On that note, I would like to announce the failure of Swiftlet’s Kickstarter campaign. We reached only 7% of our funding goal, which essentially invalidated one of the core assumptions in our early business plan: The idea that potential customers will contribute toward our product which has not yet been developed. It seems that the market has too many finished products which are similar to what ours will be.

One of Swiftlet’s core values is Transparency, not just in our source code, but also in the way we run our business. This frees us to share a lot more of what’s going on inside our heads here business-wise and hopefully learn some lessons that can be shared with other entrepreneurs. We are still in the process of getting into this experiment mindset, so stay tuned here on our blog for future business adventures.

In the mean-time, there are a couple of ways that you can still support Swiftlet Technology in our goal to change the world:

  • First, sign up for our email list in the form on the right-hand side. This will allow us to keep you updated on what is happening with the company!
  • Second, if you support our goals for open-source technology, please donate money to our cause. This will allow us to accelerate the continued development of the hardware and software. Because we are a small company, we will have to divert most of our attention to things that make money in the short-term, but any money you donate here will go directly to our open-source technologies. Also note, we are not in a position to offer rewards for these donations; if you are interested in receiving a wireless module, sign up for notification when pre-ordering is available.
  • Finally, share your opinions with us! We are dedicated to making something useful, and that can’t happen very well without being able to understand what it is that you want out of the technology! Feel free to leave a comment below or send us an email through our contact form so that we can get inside your head!

Thanks again for your support, we look forward to building this open-source, open-protocol, wireless mesh networking technology with your help!

Dan Kurin,
Founder & CEO

Hardware Specifications

Hardware Overview

In order to bring some clarity about the hardware that we are working with, I thought I would type out some quick details about the hardware that our open-source Wireless Mesh module, the Swift01, is based on. The hardware design is very bare-bones as we have made every attempt to keep this design as inexpensive as possible. Continue reading “Hardware Specifications”