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):

1. 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.
2. 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.
3. 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)
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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).
10. 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

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.

— San Francisco Open Source Policy

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.

— Vancouver Open Source & Open Data Policy

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 Open Source & Open Data Policy

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.

— Copyright Pertaining to US Government Work

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.

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!

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.

The Open Planning Project is partnering with the PenTales Storytelling Projects to develop an interactive web app for the New York City Department of Parks and Recreation. The application will serve as an interactive platform for New Yorkers of all ages to share and collaborate on stories they have produced through hand-writing, digital-writing, photography, moving pictures, voice media and other forms of communication. The platform will first pilot in New York City and will later be expanded to include other American urban and rural communities.

PenTales is seeking a talented, civic-minded volunteer developer to make the project happen. The developer will work very closely with PenTales and NYC Department of Parks and Recreation staff from start to finish, with guidance from TOPP’s developers.

The app will be built using the python-based open source Community Almanac code base. This same code is also being actively developed with other projects.

You can view the full job description on our jobs page. Please pass it on!

There’s a nice post from David Eaves today on the need for a “MuniForge” — a repository for open source municipal software.  Without getting too into the details, I wanted to point out one line that really struck a chord with me, discussing the conundrum that governments find themselves in when procuring proprietary software:

…most solutions are proprietary and so lock a city into the solution in perpetuity.  This not only holds the city hostage to the supplier, it eliminates future competition and worse, should the provider go out of business, it saddles the city with an unsupported system which will be painful and expensive to upgrade out of.

Talking to many government IT folks recently, I’ve heard this story over and over again.  The notion of a city being “held hostage” by a software vendor is a bit abstract, and is probably hard for people outside the business to grasp, but it’s a real and important problem.  To make it more concrete, and to continue to make the case for open source and open data, we should focus on telling these stories.

So, what’s your proprietary government software horror story?

At last night’s PlanningTech workshop, we diagrammed out planning processes to see where the insertion of technology might have been helpful.  The processes we looked at ranged from seemingly simple (getting a bike rack installed on your street) to massively complex (advocating for funding for MTA’s capital plan). Keep an eye out for digitized versions of the diagrams, as well as the opportunity to help expand them.

One idea that stood out, and that solicited some good discussion, was the notion of a “living plan” — a planning document that, rather than being static and falling out-of-date quickly, would evolve as a community’s context, needs, and priorities evolved.  Of course, such a plan would be unthinkable in an analog world, and seems  ridiculously obvious in a wikipedia world.

But that’s not to say it would be easy to implement.  Last night’s group raised a handful of questions, including: “what about dealing with large, complex expensive projects? (e.g., transit expansion)” and “what about blowback from early participants when the plan changes over time?”, and “what about ‘planning fatigue?’”.  All important questions to ask, and I won’t try to answer them here.  But the gist of the idea was that given a set of guiding principles (a constitution, if you will), a “living plan” might allow for more flexible planning and easier decisionmaking down the line.

It was good timing, then, that I came across this post on Streetsblog, covering some potential street design changes around Brooklyn’s Grand Army Plaza.  There’s debate over a DOT proposal to remove eastbound parking on Union Street and add a traffic lane, in order to reduce traffic buildup entering the plaza.  Community advocates are concerned that such a proposal won’t solve the fundamental “traffic vortex” problem, and doesn’t take into account the broader goals of creating a more livable and “world class” public space at GAP.

One section by the Grand Army Plaza coalition’s Robert Witherwax stood out to me:

All the tweaks to the plaza, so far, have been consistent with the planning principles GAPCo and its partners have promoted. The problem, says Witherwax, is the city’s piecemeal approach, which the Union Street proposal has cast into sharp relief. “DOT has been an excellent partner,” he said. “It’s not so much that what they have done, or are proposing, is bad — it’s that they aren’t going far enough.”

Witherwax is calling for a “buildable master plan” — a blueprint that would help guide planning and transportation decisions throughout the plaza area according to consistent goals. “Once you have that structure in place, you can say what happens if you do X, Y, and Z over here,” he said. But to date, he added, DOT has resisted the idea of a comprehensive plan.

Perhaps a “living plan” is somewhere in between the current, incremental planning that DOT is practicing an Witherwax’s notion of a “buildable master plan” — something that nurtures the development of guiding principles and longer-term projects, while still allowing for short-term experiments and responsive design.

This whole discussion makes me wonder how technology, in the form of a living plan or otherwise, might inform the debate here.  I can think of a few ways, to start:

• A website that visualizes competing plans or visions for the future of GAP, where each idea could be discussed, analyzed, and tweaked.
• An online traffic simulator (for all of Brooklyn?!) that lets anyone make tweaks and see the impacts, in a sim-city sort of way.
• A tool that explains, via an interactive diagram, the planning process as it’s currently laid out.  Who the decision makers are, where the input points are, and what the schedule is.
• Anything that generally increase sthe “touchability” of the proposed changes, moving them away from the abstract, wonky world. Perhaps this is something that our friends at the Environmental Simulation Center would be able to help with.
• (insert your idea here)

<shameless-plugs>
If you dig this kind of thing, head over to the PlanningTech google group and come to one of our upcoming meetups.  If you want to help TOPP and others build tools like these in the near future, check out the (as yet vaporware) Cosm project.
</shameless-plugs>

At the recent Technology for Participatory Planning workshop, one of the suggestions for follow-up was to look back at a completed planning process, map it out step-by-step, and find places where inserting technology might have improved things.  Frank from RPA blogged it out here.  Even just the first step, mapping out a planning process, is certainly a useful exercise.  (In fact, Rob Goodspeed and I were recently dreaming of a website that does just that for past and current projects, but that’s a subject for another post).

So, in the spirit of keeping the momentum and discussion going, RPA will be hosting an event next week, where we’ll choose a project (or a series of projects), map out the process as it happened, and then insert opportunities for technology.  Kind of a planning project autopsy.  Here are the details:

When: Wednesday 12/2, 6:30pm.
Where: RPA’s Union Square office, 4 Irving Place (the ConEd building).
Please RSVP: http://bit.ly/5aQw16

If you like this kind of thing and want to join the ongoing conversation, head on over to the #planningtech Google Group.

Hope to see you there!

We were blown away by the great turnout at last Friday’s Tech for Participatory Planning workshop.  Thanks to RPA for hosting with us, and to everyone who came out for a great afternoon of lightning talks, brainstorming, and discussion.  It’s clear that we just scratched the surface here, and we raised way more questions than answers.

The questions we closed with were: what was your “a-ha moment?”  about technology and city planning, and, more importantly, what should we do next to dig deeper into these issues?   Scanning the Blogosphere, Frank from RPA has already written up two concrete ideas: Tech / planner speed dating and Mapping the state of collaborative planning.  Both a are worth a read, and we’ll be posting other ideas here as they surface.

For follow-up, we’ve joined forces with Christian Madera, host of the excellent City Planning, Civic Engagement and the Internet Summit at Princeton last spring, and will be conversing over at the PlanningTech Google Group that came out of that event.  The raw notes from Friday’s workshop have been posted there already.

Looking forward to what’s next…