Month: October 2014

A new way to write to the White House

Official White House Photo by Pete Souza

Official White House Photo by Pete Souza

The White House has officially released the write version of the “We the People” application programming interface that now allows developers to feed data back into the petition platform via third-party applications.

“Starting today, people can sign We the People petitions even when they’re not on WhiteHouse.gov,” writes White House Director of New Media Technologies Leigh Heyman on the White House blog. “Now, users can also use third-party platforms, including other petitions services, or even their own websites or blogs. All of those signatures, once validated, will count towards a petition’s objective of meeting the 100,000-signature threshold needed for an official White House response.”

According to Heyman, more than 16 million users have created and/or signed more than 360,000 petitions.

Apply for access to the Petitions API.

Government innovation and how to make it work

A Guide for Making Innovation Offices WorkIf you, like me, have wondered whether the innovation-as-buzzword trend is having much of an impact on government today, a new, very thorough and much-needed report from IBM Center for the Business of Government addresses this issue head-on.

The report, “A Guide for Making Innovation Offices Work,” authored by Rachel Burstein and Alissa Black, covers the short history, various forms of structure, short-comings, successes and ways to improve.

“To thrive long term, though, government innovation offices must be structured, staffed, and resourced appropriately and thoughtfully, with careful attention to meeting critical needs and solving big challenges,” the report states.

Key excerpt from the executive summary:

Through our research and conversations with government leaders, it became apparent that innovation offices may not be the best way to achieve certain objectives and are not a good fit for every government organization . Some alternatives to innovation offices are presented . Innovation offices are not a panacea and more research needs to be done to understand their impact . But discrete innovation structures, thoughtfully constructed to address particular mis- sions and specific outcomes, have potential . The goal of this report is to guide government leaders in realizing the potential and limitations of an innovation office.

From my perspective, the fundamental components of long-term government innovation come in the form of open source and open data policies that are followed through on. Much of what we’ve seen to date from innovation offices is focused on short-term wins, seemingly used to help position the mayor as cutting-edge, or to provide a platform for a few key personalities inside government to talk conceptually about innovation, primarily around launching an open data or civic engagement platform.

Read the report.

Jan. 10: Celebrate your city on CityCamp Day

CityCamp

To celebrate the fifth anniversary of CityCamp, we’re encouraging cities across the world to celebrate CityCamp Day on January 10, 2015.

For those unfamiliar with the concept, CityCamp is an unconference focused on innovation and collaboration for municipal governments, community organizations and citizens.

CityCamp aims to:

  • Bring together local government officials, municipal employees, experts, developers, designers, citizens and journalists to share perspectives and insights about their cities
  • Create outcomes that participants will act upon

Here’s how to get started:

Learn more about CityCamp at citycamp.com, follow on Twitter and Facebook and sign up for the newsletter.

Please feel free to contact me at luke@govfresh.com if you have questions or need help.

Big IT vendors, civic hackers and the future of ‘Smart Cities’

'Smart Cities'

Much like “green” has done for the sustainability movement, the term “smart cities” has brought as much skepticism as enthusiasm for an ambiguous, over-marketed term used to describe the end product of the new urbanist movement.

But what exactly is a smart city?

Is it a top-down approach driven by large-scale, proprietary technology solutions orchestrated by big government technology vendors? Or, is it a more organic, distributed, modular, open source approach that expects citizens, civic leaders and the private sector to collaborate and co-create?

That’s what Anthony Townsend tries to answer in “Smart Cities: Big Data, Civic Hackers, and the Question for a New Utopia.” In the process, we get an excellent historical perspective on urban planning as a discipline, the roles and philosophies of its founders, as well as in-depth insight into the new players, from big vendors to civic hackers, emerging to stake a claim in what smart means for the city of the future.

Especially insightful is Townsend’s prescription for the future of the smart city.

While “Smart Cities” was published in 2013, it’s still a relevant and highly-recommended resource for those who want to understand the new urbanist landscape, how it’s unfolding and where you might fit in.

Favorite excerpts:

“All over the world, a motley assortment of activists, entrepreneurs, and civic hackers are tinkering their ways toward a different kind of utopia. They eschew efficiency, instead seeking to amplify and accelerate the natural sociability of city life. Instead of stockpiling big data, they build mechanisms to share it with others. Instead of optimizing government operations behind the scenes, they create digital interfaces for people to see, touch, and feel the city in completely new ways. Instead of proprietary monopolies, they build collaborative networks. These bottom-up efforts thrive on their small scale, but hold the potential to spread virally on the Web. Everywhere that industry attempts to impose its vision of clean, computed, centrally managed order, they propose messy, decentralized, and democratic alternatives.

“It’s only a matter of time before they come to blows.”

“The technology giants’ designs are a twenty-first-century upgrade to a twentieth century paternalism, an attempt to solve all of our problems for us. But in doing so, these designs fail to realize the full potential of smart cities.”

“The technology giants building smart cities are mostly paying attention to technology, not people, mostly focused on cost effectiveness and efficiency, mostly ignoring the creative process of harnessing technology at the grass roots.”

“When you create urban software, make it simple, modular and open source. Anytime you generate a new data stream, document and archive it as openly as you can.”

“So who is going to design the smarty city of the future, if the geeks on both sides of the street don’t truly grok the challenge? In the end it will be up to the mayors and their teams. They’ll hedge their bets, buying things from corporations while simultaneously seeding grassroots efforts to solve the same challenges. When that doesn’t work, they’ll just build their own. They’ll do whatever it takes to get the job done with the limited resources they have.”

DHS report outlines challenges, opportunities of open source in government

The U.S. Department of Homeland Security’s Homeland Open Security Technology projects released a report on the challenges and opportunities of open source software within government along with recommendations to address and overcome these.

The report “Open Source Software in Government: Challenges and Opportunities,” authored by David A. Wheeler, Institute for Defense Analyses and Tom Dunn, Georgia Tech Research Institute, is based on interviews conducted in 2011.

The report emphasizes the importance of case studies to highlight open source execution within government, bringing more awareness to support and warranty options, simplify code release processes and increase education around license guidance and procurement.

To no one’s surprise, issues such as fear of change, transition costs, contentment with incumbent software, lack of software expertise due to outsourcing and questions about security and code quality are inhibitors to government OSS adoption.

Key excerpt:

“Many contractors and government employees did not understand laws and policies regarding OSS. For example, a government employee stated “Federal departments are not in touch with the power already in their hands with existing policy. They are waiting for some legislation or executive order, and are not willing to stick their neck out.” Another government employee concurred, noting “There is no barrier to the use and development of OSS or public domain software.” Also, the interviewers encountered pervasive use of the term “commercial software” as an antonym of OSS. Yet U.S. law defines commercial software in a way that includes most OSS.”

Full report

Help get USDA to lead with APIs when it comes to America’s parks

Photo: USDA

Photo: USDA

I need your help with something.

I’m in the business of helping startups, all the way up to our federal government, identify valuable assets and make them more accessible for use in websites and mobile devices. As part of this work I’m always on the look out for valuable public assets across city, state and federal government, and help make sure the conversations around these assets always include application programming interfaces, so that we aren’t just building web and mobile applications in silos, and limiting the potential for public access by individuals and small businesses.

Over the last couple years, I have cultivated a small group of API evangelists in various sectors who help keep me informed of important government projects. One of my partners in crime, Alyssa Ravasio (@alyraz), brought a pre solicitation for a request for proposal to my attention from the U.S. Department of Agriculture, for a “Recreation On Stop Support Services” to my attention. You can see this service in action at Recreation.gov. In short, this is an ongoing contract that our federal government engages in with a private sector contractor to provide access to our nation’s campgrounds and campsites at our federal parks.

I would put our national parks and campgrounds at the top of treasured assets that this country possesses, and something that we need to make sure continue to be as accessible to individuals and small businesses as possible. I want to take the time to respond to the pre-solicitation from USDA, in hopes of helping them craft a better RFP before this goes out to bid.

I also want to encourage others, who are also passionate about camping and our national parks, to submit their own feedback to USDA’s solicitation number AG3187S151000–Recreation One Stop Support Services.

The current incarnation of the one stop service for recreation project has an API. Well, it has web services as part of the existing Recreation Information Database, but you also find mentions of API in the proposed RFP, under the 5.3.9 Mapping and Geospatial Capability:

A segment of the user community will not only be accessing and viewing the mapping data through the web interface at www.recreation.gov, but will also have a need to search, retrieve, and download the geospatial data via the RIDB data sharing interface(s), or APIs. The Contractor shall demonstrate utilization of programming languages, formats, data types/conventions/sources, etc. which maximize the portability and usability of maps and map related data by third-parties. This minimizes the need for third-party data consumers to procure expensive and/or proprietary software to utilize, edit or manipulate the mapping data. The contractor shall ensure that all available geospatial data within R1S is incorporated into the user interface to provide users with the most complete mapping solutions available.

There is another mention of APIs under “5.3.6 Provide Travel Planning Tools” with:

Non Federal reservable inventory may include state and local reservable and non-reservable recreation inventory which may be incorporated into the system or accessed via various application programming interfaces (APIs).

Then, towards the end you see the following needs:

  • Data Sharing and Data Management – Information originating from within RIDB and imported shall be presented in a manner such that the external origin of the data is transparent to users and consistent with presentation of information originating from within.
  • Information Sharing – The Contractor shall deliver automated and manual services for the sharing of the consolidated recreation information described herein. The sharing service shall utilize prevailing industry best practices and technologies to make the consolidated recreation information publicly available to data consumers.
  • Information Consolidation – The Contractor shall deliver automated and manual services for collecting of a wide variety of recreation information from a wide range of sources including Federal Government Agencies and Federal Partner organizations such as Historic Hotels of America.

To me, all of this infers that whoever wins the contract will need to at least maintain what is available via the RIDB, which is nice, but it is just a web service, not a modern web API, and only reflects providing access a small portion of the valuable resource that will need to be made available via Recreation.gov to partners and the public at large. We can do better.

An API needs to be a first-class citizen in this RFP, something that is not just an afterthought and a connection to the database that just needs to be maintained — an API will be central to deliver the resources needed for a “one stop services for recreation”.

Camping resources

When you look through the requirements for this project, you see all the building blocks for allowing individuals to engage with campsites across our nation, inventory, ticketing, lotteries, permitting, day use and group facilities, special events and use, equipment rentals, recreational and pass sales. All of this keeps our national parks accessible to campers.

Mapping and geospatial resources

Camping resources are meaningful to us because of where they are located. Mapping and geospatial resources will be vital to enabling users to discover the parks and campsites where they wish to stay on their camping trips. The ability to search and navigate campsites via modern mapping and providing geospatial resources is central to the one stop service for recreation.

Financial resources

A third cornerstone of the recreation one-stop support services platform are the financial resources. The ability to accept and process credit cards, cancellations, modifications and refunds will play a role in every engagement on the platform. Access to to all aspects of commerce via the platform will make or break operations at every level for the one stop service for recreation.

User resources

The fourth corner of the one stop service for recreation platform is the user. Providing secure, seamless access to user profiles and history throughout the Recreation.gov experience will be critical to it all working. User resources are central to any modern web or mobile application in 2014 and depends on camping, geo and financial resources to bring it all together.

Recreation.gov website

All of these resource need to be made available on at Recreation.gov, in the form of fully functioning web application providing a content management system (CMS) for managing the site, complete with a reservation system that allows users to discovery camping resources, via mapping geospatial resources, and pay for their reservations via financial resources—all via a secure, easy to access user profile.

Travel planning tools

Beyond the core public website and its reservation system the requirements call for travel planning tools including point-to-point itinerary planning, field sales and reservations sales, third party sales and reservable inventory management. While these tools are likely to primarily be web-based, the requirements call for remote sales and management of inventory, which requires a central API solution.

Robust reporting solutions

Reporting is prominent through the requirements requiring web analytics, canned reports, customizable reports, monthly performance reporting, and enterprise reporting systems. In short, reporting will be essential to all aspects of the one stop service for recreation for both the contract winner and operator, as well as all of the agencies involved. I would add in that end-users will also need some views into their own Recreation.gov usage, adding another layer to the conversation.

Data accessibility and portability

Another element that is present throughout the requirements is data access and portability of the camping, reservation, customer (user) and resulting financial data. Pretty much everything in the system should be accessible, right? This definitely goes beyond just what is available via the RIDB and requiring all aspects of the one-stop service for recreation to be accessible for use in any other system, or just as download.

Minimum required applications and platforms

As part of the requirements, there is a minimum requirements for browsers, and mobile platforms that the one stop service for recreation should operate on:

  • Applications:
    • Microsoft Internet Explorer
    • Mozilla Firefox
    • Google Chrome
    • Apple Safari
  • Platforms:
    • Android Mobile Devices
    • Apple iOS Mobile Devices
    • Apple Desktop OS
    • Microsoft Windows Mobile Devices
    • Microsoft Windows PC

For me, this portion of the requirements are extremely vague. I agree that the Recreation.gov and travel planning tools should work in all these browsers and be responsive on mobile browsing platforms, but these requirements seem to allude to more without actually going there. In 2014-2016, you can’t tell me that native mobile experiences won’t be something end users of Recreation.gov and the overall system will be demanding? Mobile will be the gateway to the platforms mapping and geospatial resources, and APIs are how you deliver the resources needed for developing mobile applications on all of the platforms listed.

A one-stop service for recreation requires a multi-channel approach

The one-stop service for recreation requires a multi-channel approach to deliver the camping, mapping and geo, financial and user resources to the main Recreation.gov website, supporting reservation system, travel planning tools, reporting solutions and potentially any other web or mobile applications, and round it all off with needing to provide the data accessibility and portability that is demanded of a modern federal government platform.

Transform the RIDB web service into a modern API and make the center

The only way you will engage with users Recreation.gov on the web and mobile locations they will demand, as well as deliver the reservation, travel planning and reporting solutions, while making sure everything is portable, the RIDB database and supporting web services needs to be brought up to date and transformed into a modern web API. The RFP_-_Attachment_10_-_Notional_Future_RIDB_Data_Flow_-_Sep._22_2014.pptx even reflects this vision, but the actual RFP severely falls short of describing the role an API will play in the platform.

Making security a priority across all aspects of operations

With a single API layer being the access layer for all web, mobile, reporting and data accessibility channels, security takes on a whole new meaning. APIs provide single access point for all access to platform resources, allowing security and auditing to occur in real-time, using modern approaches to API management. APIs use existing web technology and don’t require any special technology, but do provide a single layer to enable, monitor and deny access to all resources, across the one-stop services for recreation.

A centralized metrics, analytics and reporting layer

Married with security, an API-centric approach allows for a platform-wide analytics layer that can drive security, but also provide the data points required for the overall platform reporting system. With an API analytics layer this data can be delivered to platform, government, developer and end-user reporting solutions. A comprehensive metrics, analytics, and reporting strategy is essential to a modern one stop services for recreation platform.

APIs let in the sunlight, enforcing transparency and accountability

One critical aspect of a modern, API-centric approach is the transparency and accountability it provides. All database connections and web or mobile applications are brokered via an API layer, requiring all applications to rely on the same pipes for reading, writing, modifying and removing data from the system. This approach provides a secure window into all aspects of platform operations, providing the accountability requirements set forth in the proposed RFP.

Some constructive criticism for language in the proposed RFP

There are some points in the proposed RFP that, in my opinion, move the conversation backwards rather than looking to the future and fulfilling a vision of what the “one stop services for recreation platform” could be.

One example is “5.3.6.3 Third Party Sales”:

The Government anticipates that during the potential 10-year period of performance after go-live there may be an interest by commercial travel and recreation planning companies (such as Travelocity, Expedia, etc.) to utilize R1S inventory and availability data to facilitate R1S transactions. The Government may be open to such Third Party Sales arrangements, provided the business, financial and legal terms of the arrangement are in the Government’s best interests. At the Government’s request, the Contractor shall lead exploratory meetings, including Government and applicable industry representatives, to determine commercial interest in such a service and also explore the technical and fiscal feasibility of such Third Party Sales arrangements. Upon the conclusion of all necessary exploratory meetings, and should the Government decide to implement Third Party Sales, the Government will issue a formal modification to the R1S Support Services contract to incorporate the service. There is no requirement for the contractor to provide Third Party Sales services until a post-award modification is issued requiring them.

“There may be an interest by commercial travel and recreation planning companies (such as Travelocity, Expedia, etc.)?” In the current online environment, I am pretty sure that this shouldn’t be “may,” this should be “will,” and that the pace of business today moves quite a bit faster than this section describes. APIs enable a new approach to business development that was coined 10 years ago by the co-founder of Flickr, the popular sharing platform.

I understand that you will have to certify developers, but this should not get in the way of small business developers experimenting and innovating with the resources available via the platform. Business development via an API has been going on in the private sector for 10 years and isn’t something USDA should be putting off until the next procurement cycle for the platform.

The proposed RFP states:

The current contract is a Variable Quantity contract with Fixed Price per-transaction pricing such that the Contractor earns a fixed fee for each transaction processed via the www.recreation.gov website, the telephone customer support line, or in-person at participating Federal recreation locations.  The fixed fees under the current contract vary depending on the type of inventory being reserved, the sales channel, etc.

In an era where we have over 10,000 API resources to use in applications, where cloud-based utility pricing is successfully being applied, and you pay for what you use across numerous industries, you can’t have a business model like this for a public-private sector partnership, and not put APIs to use, and enabling trusted partners to build a business model around the commerce opportunities available via a platform. Right now, this is exclusive to the current contract holder, Active Network, d.b.a. ReserveAmerica, and for the next round should not be something that is exclusive to the contract winner. It should be open to the thousands of businesses that serve the parks and recreation space.

Another item I have an issue with is ownership over the source code of the platform:

The Government owns all of the inventory, transaction and customer data associated with Recreation.Gov; however the reservation system remains the sole proprietary property of the current service provider.

I know this is the current situation, but I strongly urge that for the next relationship, this is not the case. The government should own all of the inventory, transaction and customer data and the reservation system should be open source. Period. The chances that there will be innovation via the platform if it remains a proprietary solution is slim and requiring that the core reservation system and supporting API platform remain open source will stimulate innovation around Recreation.gov. Any business, including the winner of the contract, can still build proprietary solutions that use the API to deliver specific applications, or end-user solutions and premium features, but the core software should be open this time.

Some praise for what is in the proposed RFP

I am not one to just criticize without providing at least some praise, acknowledging where USDA is looking towards the future. One area I have to note is their inclusion of the U.S. Digital Services Playbook, where #3 on the checklist for deploying in a flexible hosting environment is “resources are provisioned through an API,” and #2 on the checklist for defaulting to open says that you should provide data sets to the public, in their entirety, through bulk downloads and APIs (application programming interfaces). I think the U.S. Digital Services Playbook should be included with ALL federal government RFPs, and it makes me happy to see it in here.

I also understand the number of agencies involved in the project include USDA Forest Service, U.S. Army Corps of Engineers, U.S. Department of the Interior (including at least the National Park Service, Bureau of Land Management, and Bureau of Reclamation, Fish and Wildlife Service), the National Archives and Records Administration and other potential federal partners to be determined at a later date.

Agencies involved in the trip planning component include the agencies named above, as well as the Department of Transportation; Federal Highway Administration, the Department of Commerce; National Oceanic and Atmospheric Administration, the Tennessee Valley Authority and Smithsonian Institution. This is a huge undertaking, and I commend them on the effort, but can’t also help myself in throwing in that this is all the more reason the one stop-services for recreation has to have an API. ;-)

In closing

I think I’m finished with my response to the Department of Agricultures’s solicitation number AG3187S151000–Recreation One Stop Support Services. I would like to request that they extend the deadline for response for another 30 days, to allow me to drum up more feedback, as well as put some more thought into the RFP myself. Following your own lead of including the U.S. Digital Services Playbook, I would also recommend bringing in:

  • 18F – Building on the U.S. Digital Services Playbook, 18F has an amazing set of resources to help USDA move forward with this RFP in a way that is in line with other leading platform efforts in the federal government—please make sure 18F is involved.
  • Round 3 PIFs – This is probably already in the works, but make sure there is someone from the recent round of Presidential Innovation Fellows are on board, helping make sure this project is headed in the right direction.

Ultimately, I think all the right parts and pieces are present for this project, but when it comes to  finding the right language, and vision for the RFP, it needs a lot of help, and I’m confident that 18F and PIFs can help bring it home. The most important element for me is that web service from the RIDB needs to be transformed into a modern web API and brought front and center to fuel every aspect of the platform. I’m confident that if the RFP speaks the right language, the winning contractor will be able to translate the RFP into the platform it needs to be, and serve the expectations of the modern consumers who will be using the platform in coming years.

If this RFP goes out the door without an API vision, planning of the family camping trip will done in a silo, at Recreation.gov, and not on the mobile phones that are ubiquitous in our everyday life. User do not need a web experience that is translated to function in mobile browsers, they need a web experience when it makes sense, and a native mobile experience, and even offline when necessary.

Planning the family vacation will not happen from just Recreation.gov. It needs to be part of a larger vacation planning experience, occurring via the online platforms we already use in our daily lives. If USDA focuses on an API-first vision for delivering the one stop service for recreation, it will live up to its name—truly being a one-stop service that can be used for planning your recreation from any platform or device.

Call to action

Visit USDA’s solicitation number AG3187S151000–Recreation One Stop Support Services and ask them to extend the comment period, and let them know how important it is that the platform is API-centric. Feel free to send me a link to your of feedback, and I’ll add a list of relevant stories to the bottom of this post as I find them.

Doubling down on government technology

Photo: Luke Fretwell

Photo: Luke Fretwell

We’ve recently seen an uptick in venture capital interest around government and civic technology startups, but before we enthusiastically celebrate these investments, we must ask ourselves whether this potential bubble will truly reshape government IT or simply leave us five years from now in the same place we are today.

During the Code for America Summit in September, Govtech Fund’s Ron Bouganim and Code for America Director of Products & Startups Lane Becker had a great “Emerging Startup Ecosystem” discussion about the the difference between civic and government technology, and the latter’s focus on solving inherent bureaucratic problems.

Bouganim’s closing comments have stuck with me since watching the interview, and they’re important for us all to think about as we commit to building technology solutions, whether it’s for internal government operations or public-facing citizen engagement applications:

“It is tough because it’s early. Clearly everybody in this room is transformers. These are the folks … that are at the front of this, so it’s tough, because you often at times feel alone, but I think there’s a growing community, and it’s only going to get better. So, I guess my fundamental advice is that if you’re really passionate about this space, and you really identify a big problem, you have to kind of double down on being an entrepreneur. It’s hard enough being an entrepreneur and, in an emerging space like gov tech, you have to double down on that, and I would just encourage you to stick with it.”

Announced in September, Govtech Fund will invest $23 million into government-focused technology ventures. Recently, Y Combinator also expressed an interest in the industry when it issued a request for startups that included those focused on the public sector. Andreessen Horowitz has already invested $15 million in OpenGov, focused on bringing visualizations to government budgets. Other startups such as Socrata and MindMixer have also received multi-million dollar infusions to build the future of public sector IT.

Given the consistent inability for government projects to deliver on time or on budget, especially in the light of recent, major IT failures, we’ve collectively identified the problem. While much of this is due to culture, bureaucratic procurement processes and waterfall project management practices, the fundamental issue with failed government IT is that it is built on proprietary solutions.

Because of this, not only do we not have access to code, more importantly, we lose an opportunity to create an ecosystem of community and collaboration that sustains itself. To put it in context of the latest civic meme, today’s government technology is built for, not with.

The early trend we’re seeing in government technology venture investments is that the focus is still on the proprietary. While this will have incremental benefits and provide short-term excitement with each new launch, they don’t address the bigger issue every government faces in harnessing control over their IT systems.

They’re locked down and locked in.

The argument you often hear when discussing open source with proprietary government technology startup entrepreneurs is that businesses need some form of competitive advantage to build a product and develop a customer base with enough runway to sustain itself longer term. While this makes sense in a commercial market, it addresses the needs not of government, but that of the entrepreneur. The technology may provide a cutting-edge, cloud-based, big data, mobile or social solution worthy of a press release or mention in the trades, but what is it doing to really change the IT conundrum we can’t seem to procure our way out of?

This isn’t to say these new technologies don’t have merit or their builders don’t have good intention. Indeed, some do, however, there’s a classic innovation wall proprietary government IT software hits when it has reached a certain level of customer acquisition and no longer needs to compete. Oakland’s recent insistence that Granicus open up its application programming interface is exhibit A on what happens when a vendor corners a government market: technology stagnation trumps innovation. Without open systems or modularity, government is safely locked in.

We frequently hear the vending machine analogy applied to government. Today, the vending machine is the proprietary vendor machine, and government is the one doing the shaking.

If we’re going to double down and truly build a civic operating system anyone can plug into, and be proud of, we must invest in a strategy that sustains beyond one software solution.

We need to double down on a philosophical approach to government technology.

There’s not an overnight solution and the problem won’t be solved tomorrow, but if you’re really in this business to transform government, whether you’re an entrepreneur or investor, it’s time to double down on open.

Government can, literally, no longer afford to operate business as usual when it comes to technology. If ‘Vendor 2.0’ is simply a new class of fresh faces operating no differently than its predecessor, let’s prepare our kids for disappointment.

You’re either investing in or building tomorrow’s problem today, or you’re co-creating the future of government.

The latter might be a longer, lonelier road, but we have to stick with it because, as Bouganim says, it’s only going to get better.

Let’s double down.

Watch the full video of Becker and Bouganim’s discussion: