We're an incubator for civic tech initiatives at The Open Planning Project. We believe in open data, open source, and running code. We blog about this stuff, too.
From our blog
Recently, we’ve been working with a lot of public agencies (mostly in the transportation sector) who are interested in setting up developer conferences or app contests. While we are big fans of both conferences and contests, our main point of advice has been get away from thinking just about conferences & contests, and focus on building an holistic developer outreach program. Since we’ve been having these discussions mostly through private channels, we also wanted to put our thoughts out there for everyone. So, below is the initial list of recommendations we’ve been developing:
Focus on building a holistic and sustainable developer program & community, not a one-off
conference or contest. The ultimate goal is to encourage developers to build apps that improve the civic
experience. Conferences and contests are important pieces of the puzzle, but aren’t complete solutions on their own.
Release early and often. It’s a bit counter-intuitive, but this actually reduces risk, since it allows for
constant feedback and readjustment, which helps you avoid veering off on the wrong track. Small,
incremental improvements, coupled with avenues for feedback from developers, will cultivate a
stronger and more sustainable community.
Speak developer. Be genuine, open, and responsive. Good examples of this are BART’s recently
redesigned developer website and the tone that MassDOT/ MBTA has struck on their Google Group.
With these ideas in mind, here are ten specific recommendations for how to build a robust
developer community (in this case focusing on transit, specifically, but the basic principles apply to all sectors):
- Choose one or two people in the agency to be a consistent presence on the Google Group and at meetups. This will help build trust and improve developer relations by putting a human face on your developer policies.
- Start with a friendly and honest introduction on your Google Group, and invite developers to be part of the process – to be active allies and not a passive audience.
- Schedule your first meetup. At the end of that meeting, decide with the attendees when to schedule the next one (in two weeks, in a month, depending on interest and current activities)
- Show progress by making incremental improvements to the data sets and by releasing new sources of data. Don’t try to guess what developers might want; just ask them. This becomes increasingly easy to do as you build relationships with more and more developers.
- Be clear and honest about the constraints when releasing data: if it’s not logistically or economically feasible to release certain data sets, say so.
- After you have held a few meetups and have gotten to know the developer community, plan your conference or contest. A good format would be a hybrid unconference/conference, with organized introductory speakers and unconference slots in the afternoon. Weekends are best, as is starting after 11am. Once you have an active relationship with the developer community, they can help you plan aspects of the conference.
- If you want to do an app contest and announce the winners at the conference, you will need to build in more lead time to ensure that developers have time to build high-quality, useful apps.
- When considering keynote speakers for a dev conference, consider both tech industry leaders as well as high-ranking agency representatives, to demonstrate agency buy-in.
- Prizes: tours of publicly inaccessible areas, including control rooms, bridges, abandoned tunnels, or construction zones, would be great prizes. A chance to use a train or bus simulator would also be an exciting prize for transit developers, specifically (MBTA gave away a session in the bus simulator as well as “golden” Charlie Cards as prizes in their app contest).
- Most importantly: don’t think that you need to have all the answers. The sooner you can reach out and engage with the wider developer community – even with just a few messages to the Google Group – the sooner you can benefit from the feedback, ideas, and energy of a much larger base of supporters.
As you know, there are examples of other agencies who have taken many of these ideas to heart, most
notably the MBTA, BART, and TriMet. Looking closely at what each of these agencies has done is the first step towards developing a successful and sustainable dev program.
Written by Nick Grossman and Nicholas Bergson-Shilcock
0 Comments
Filed under Community Involvement, Open Data Tags: app contests —
12:44 pm on February 12, 2010
February 9th Update: This post originally limited focus on the declaration of “equal” within these three cities open source policies, but I have expanded to also cover the issue of defining “open source” and stipulating open source licensing for code developed in-house.
San Francisco recently established a new policy requiring open source software to be considered equally with proprietary software within the city’s procurement process. It’s important to note the actual inclusion of the word “equal” in this policy. Emphasis here is mine:
The Software Evaluation Policy will require departments to consider open source alternatives, when available, on an equal basis to commercial software, as these may reduce cost and speed the time needed to bring software applications to production.
This is much like the legislation passed in Vancouver last May:
The City of Vancouver, when replacing existing software or considering new applications, will place open source software on an equal footing with commercial systems during procurement cycles.
Back in September, I think Portland actually initiated the “First-In-Nation Open Source Software Policy for City Government,” but the language in Portland’s resolution is definitely not as strong:
Establish best practices for analysis of business requirements in software review and selection processes, identify existing commercial software systems with licenses that are scheduled to expire in the near future, and encourage the consideration of Open Source Software in the review, replacement and continual improvement of business solutions;
Portland’s resolution should be amended from “encourage the consideration” to “require equal consideration” and other cities should make sure that they provide measurable policies for using open source rather than simply to “encourage consideration.” Some other important things to include within open source policy is a definition of open source and how open source licensing relates to new software created in-house.
The definition of “open source” included in San Francisco’s policy deviates somewhat from most common definitions of open source software:
Open source software means that the underlying source code is not copyrighted and therefore available free of charge to read, modify, and build upon.
Typically, the authors of source code retain copyright to their contributions, but their contributions are covered by open source licenses that allow others to use, distribute, modify, and build upon the code. SF Apeal details this and covers some other criticisms including the fact that San Francisco’s open source policy is only enforced for software purchases that exceed $100,000. For a comprehensive and standardized definition of open source software, see The Open Source Initiative’s Open Source Definition.
The Vancouver legislation does not explicitly define open source, but it does specify how the city should license the software it develops:
License any software applications developed by the City of Vancouver such that they may be used by other municipalities, businesses, and the public without restriction.
As cities include third party open source software as part of their IT policies they should also be sure to apply open source licenses to the software they develop in-house. Open licensing is often the case with government data (especially since U.S. Copyright does not cover factual data), but open source licensing should be more explicitly applied to publicly funded technology, especially government produced source code. In general, when the U.S. federal government produces work it is automatically part of the public domain, but this policy does not always apply to local governments.
A work that is a United States Government work, prepared by an officer or employee of the United States Government as part of that person’s official duties, is not subject to copyright in the United States and there are no U.S. copyright restrictions on reproduction, derivative works, distribution, performance, or display of the work. Anyone may, without restriction under U.S. copyright laws,
- reproduce the work in copies in print or in digital form;
- prepare derivative works of the work;
- perform the work publicly;
- display the work;
- distribute copies or digitally transfer the work to the public by sale or other transfer of ownership, or by rental, lease, or lending.
Many local open government initiatives have been influenced by the open government initiatives on the U.S. federal level and open source has been part of these developments too. The White House, the Department of Defense, NASA, and many parts of the federal government now have a focus on using and developing open source software. Yet in many ways the argument for open source is much stronger on the local level where there are so many shared needs and so many wheels being reinvented.
The developments in Vancouver, Portland, and San Francisco are huge and these cities deserve to be lauded as great pioneers, but we also need to help support them and to spread these kinds of policies to other cities. You can learn more about this and contribute to the creation of resources for open cities with the nascent OpenMuni project. I also highly recommend you read David Eaves post about Muniforge which describes the value and opportunity of an open source civic software ecosystem.
When you think of iterative development, you’re unlikely to also think “government agency.” You’re even less likely to think “MTA.”
But that might not be the case in the future, as today the MTA showed a strong sign that the situation is changing: They listened to feedback and responded. Quickly.
In my post yesterday, I identified several aspects of the new developer resources page that could be improved. On Thursday and today I had more communications with representatives from the agency and provided some additional feedback.
This afternoon — less than 48 hours after my post went online — they addressed several of my suggestions for improvement. First, they’ve significantly streamlined the download process, replacing a form requiring lots of personal information with an optional one that simply asks for your email address — so you can be notified of data updates — and what you plan to use the data for. This information is entirely optional as there is also now a link to take you directly to the download page.
Second, they explicitly added information about how frequently the schedules are updated, as well as upload dates for each of the datasets.
Lastly, they’ve posted GTFS data for the MTA Bus Company. This is another big milestone, as it means that now every single MTA transit agency has its data online, for free, in GTFS.
These changes — along with the rapidity with which they were made — show that the MTA is serious about open data and proactively working with the developer community.
For an agency that gets a lot of flack (both unwarranted and warranted), they deserve credit where credit is due. Bravo, MTA!
It’s here: The MTA has officially launched its redesigned website, complete with a spiffy new look, access to multiple trip planners, and a convenient way to quickly check on the status of subway and bus lines.
While there’s much to say about the site’s new design, what excites us most is the developer center, which I think is the most important announcement of the day. Here’s a quick rundown of the news, starting with…
…What’s good
Before talking about the new stuff, it’s useful to think about just how far things have come in a relatively short amount of time. Just five months ago, developers were being threatened with legal action by the MTA, the only way to get any raw schedule data was to submit a formal FOIL request (and get a CD weeks later with data in an undocumented and cryptic format), and there was no good avenue for developers to positively engage with the agency.
Contrast that with the situation today: The MTA has released GTFS data for the entire subway system, NYCT buses, Metro-North Railroad, Long Island Rail Road, and Long Island Bus. This is a tremendous and welcome step forward. With the click of a button, developers now have access to the majority of the schedule data for NYC trains and buses, all in a standard format.
Also encouraging is that the MTA has expanded its Twitter (and Facebook) presence. Follow @MTAInsider for updates from inside MTA HQ. Here’s hoping the agency uses this as an opportunity to listen as well as talk to the transit riders.
…What needs to be improved
Personal information shouldn’t be required just to download the GTFS. I understand why the agency has an interest in collecting developers’ email addresses, but I think the download process should be as simple and straightforward as possible. Right now, the process is overly complicated, requiring everything from a street address to your phone number to the IP address range where your application will be used. This information should all be optional. You should only need to enter your address if you want to receive emails when new schedules are posted.
There is no MTA developer mailing list. Such a list would be a fantastic resource and would greatly improve communications between the MTA and the developer community. This could be easily implemented and hopefully will be soon. Other agencies, such as MassDOT, have seen great success using a public mailing list to engage with developers.
Another issue is that there’s still not a clear path for applications to freely and easily use the standard route markers to properly identify lines. A clear, click-through license that explicitly grants usage of these symbols for such purposes — for both commercial and non-commercial use — would be another important step forward. It would also further the social goal of trademarks: reducing consumer confusion in the marketplace, making it easier for riders to get information on their preferred bus and subway routes.
Missing from the data sets released today is schedule data for the MTA Bus Company, which operates a significant portion of the buses in New York City, and the Staten Island Railway (Update: Looks like the NYCT Subway GTFS includes the SIR schedule!). However, my guess is that it is only a matter of time until this data is also released. Other datasets — from ridership numbers to greater facility information — would also be welcomed. Hopefully these and other datasets are on the way.
One such dataset that’s of particular interest to me is subway entrance and geometry data. The MTA has previously made the argument that releasing such data would pose a security threat, but this seems far fetched, particularly since all of this data has already been released, just in a manner that’s less useful for developers. The neighborhood subway maps, which are displayed prominently in subway stations throughout the city, show the station entrances and geometries, and the NYCityMap operated by NYC DoITT has a GIS layer with the location of every single subway entrance.
The final big omission is the lack of real-time data. Since such data doesn’t exist for most of the system, it’s unreasonable to expect it to be released today. However, there is some real-time transit data in New York — namely for the L train and the 34th st buses in Manhattan — and this information should be released for developers to build applications on top of.
…What’s unknown
One big unknown is how weekly service advisories will be handled. With so much weekend track work going on, everybody knows that subway service can change dramatically come Friday nights. Weekly service alerts and schedule changes, provided in a well structured and machine-readable format, would be immensely useful and help ensure that transit apps provide riders with the most accurate information possible. With the MTA now defaulting to Google’s trip planner on its homepage, the need to get updated GTFS data out on a regular basis is particularly acute.
The second big unknown is how responsive and open to developer feedback the agency will be. The announcement today suggest they are serious about leveraging the outside development community, and I have witnessed a palpable shift in the agency’s willingness to engage over the past several months. Here’s hoping that things will continue moving in the right direction.
…What’s next
These improvements did not come about easily. There were substantial logistical, legal, and political hurdles to overcome, and I know many people, both inside and outside the agency, worked hard to bring about these changes.
The NY Open Transit Data group has long been advocating for these changes and working to constructively engage with the MTA. I’m pleased to say that today’s announcements incorporate some of the core recommendations we’ve made to the agency on open data policy. Our group’s next meetup is Wednesday, January 20 at 6:30pm. Come join us to talk about what these developments mean, what’s next, and, most importantly, how we can use this newly opened data to improve transit in New York.
I’m proud that the city I call home has joined the ranks of those providing open transit data, and I can’t wait to see what comes next, both from the the MTA and the New York tech community. It’s going to be another great year for open data.
Update 1/15/2010: Two days after writing this post, the MTA has already addressed several of these issues!
The quest for open transit data in New York continues, but the Times’ coverage today of the upcoming launch of the MTA’s new website gives cause to be optimistic. As the Times reports, the MTA is set to launch a redesign of its website this Wednesday, giving the agency’s site a much needed — and appreciated — overhaul. The overall design of the site looks to be greatly improved, and the subway service status on the front page is alone reason to celebrate, as anyone who’s been bitten by weekend service changes will surely understand.
Another welcome change is the addition of the trip planner to the front page. Interestingly, the default option now uses Google’s transit planner, though the screenshots reveal that you’ll also be able to plan trips using either Trips 1-2-3 or the in-house MTA trip planner.
The most exciting part for open data geeks though is this promising morsel:
The new site will also make it easier for outside software designers to get free access to system timetables and routes.
The article contains no further information about what this means, though the screenshot does show a “Developer Resources” link on the lower right-hand corner of the page.
The MTA has hinted for a while at changes to its developer and licensing policies, but beyond the cessation of legal threats last August, there’s been virtually no public announcements on the topic. Many people, including those of us here at TOPP who founded the NY Open Transit Data group, have long advocated and worked to open up New York’s transit data. We’ve had increasingly positive interactions with the MTA, particularly since the arrival of chairman and CEO Jay Walder last October, but are still waiting to see results.
It’s unlikely that the launch on Wednesday will be perfect, but I think it will prove to be a significant step toward the goal so many of us share: universal access to free, complete, and up-to-date transit data for New York.
It looks like it’s going to be a good week for open data.
