We’re moving our blog!
We’ve updated our main website, https://18f.gsa.gov, to directly include our blog posts. For the curious techies, it’s now a Jekyll site and we’re using Markdown + Github to manually manage our blog posts.
We will likely use this Tumblr in the future for adjacent projects, but for now please bookmark https://18f.gsa.gov/news for future blog posts.
18F Open Source Hack Series: Midas
By Sarah Allen from the Midas team
One evening can make an impact!
18F invites designers and developers from inside and outside of government to join us for a flurry of coding and sketching.
Midas is an open source project in active development by 18F, Health & Human Services (HHS) IDEA Lab and the State Department. A small cross-agency team, dedicated to launching this product to empower passionate civil servants and aspiring diplomats all over the world.
What is Midas?
Midas is an online marketplace of skill building opportunities which matches people to projects that they’re passionate about. Our goal is to foster innovation across team boundaries by connecting projects or challenges that need help within federal government agencies to people who want to work collaboratively on the solution.
"It’s like a Kickstarter for people’s time." –Joe Polastre at 18F Demo Day
Please join us
Monday, October 6, 3–9pm
18F/GSA Headquarters, 1800F Street (map)
- 3-5:30: afternoon session: write code, create designs, paper prototyping
- 5:30-6p: How will Midas improve government? special guests plus Q&A
- 6p-8:30p write code, create designs, paper prototyping session
- 8:30p demos & sharing what we’ve learned
We’re building the future of government, but we need your help! We have a stable backlog and a few individuals can make a huge difference. Feel free to come for the afternoon or evening session or both! You can work solo, in pairs or groups that will form when we get there.
Sign up now!
Designers, UX or usability folks: We have a lot of issues tagged design. You can work on mockups or detailed deisgn suggestions. If we have enough people we could even do some informal usability test sessions!
Developers Check out our contribution guide — all of our code is public domain. For coders, we’d love some experts to join us, but open source is also a great place to learn and hone your skills. Here’s a list of some of the tech we use:
Sign up by Thurs., Oct 2 to reserve your spot!
User-centered design at 18F: a design studio for natural resource revenues
By by Chris Cairns, Michelle Hertzfeld, and Nick Bristow
On July 28, 18F kicked off a new project with the Department of the Interior’s Office of Natural Resources Revenue (ONRR).
Later this year, ONRR will be launching a new website — originally prototyped by Round 2 Presidential Innovation Fellow Michelle Hertzfeld — to facilitate national and international conversation around U.S. extractive industries revenue. It will serve as a valuable resource for data and information about U.S. extractive industries on Federal land, and will also provide interactive visualizations that can be readily understood and accessed by the public for reuse through other media and applications.
This will all be a part of the U.S. implementation of a global transparency standard for natural resource governance called the Extractive Industries Transparency Initiative (EITI). EITI is a global coalition of governments, companies, and civil society working together to improve openness and accountable management of revenues from natural resources including but not limited to oil, natural gas, and coal. The U.S. is the first G7 country to sign-on to and implement the new EITI standard. To learn more about the U.S. process for implementing the EITI standard, check out the USEITI homepage.
18F’s task is to refine Michelle’s original design and develop a simple and informative experience for:
- members of the general public who want to learn about U.S. extractive industries revenue and how these revenues impact them on a local level;
- researchers and data scientists who want access to the raw data for analysis purposes.
Over the course of a project, we often conduct one or more workshops. Three weeks into the USEITI project, we decided to hold a design studio to solve the problem of how to convey complex revenue data. We needed to better understand the difference between onshore revenue (revenue from natural resources extracted from land) and offshore revenue (revenue from resources extracted from Federal offshore or the U.S. outer continental shelf) as it relates to our system.
What’s a design studio?
A design studio is a structured workshop that guides its participants through the process of understanding a problem. Through sketching, presenting, and critiquing ideas, the goal is for the group to arrive at a shared vision of a potential solution to the problem at hand. In our case, our shared problem was how to convey complex information about natural resource revenue in an intuitive way.
Ideally, a design studio brings together a group of people with diverse and balanced skill sets (for example, design, product management, and domain expertise). These diverse people bring diverse ideas, which in turn create unique and high-quality joint outcomes. If you can draw a stick figure, then you can be an effective design studio participant!
How Does It Work?
In the case of USEITI, we invited representative users and stakeholders from both inside and outside of government to participate in a 4-hour workshop.
First, we laid out the ground rules:
- Everybody is a peer
- Start with user needs
- No saying “no” to things
- Everybody draws
Next, following a round of introductions, we dove right into the collaborative design process.
Creating user personas. Based on the participants’ previous research on users, the group developed user personas to serve as examples of the types of people who would interact with the website. We did this by brainstorming possible user goals, behavior patterns, skills, attitudes and environments, and then condensing these into representative groups through affinity mapping. The resulting personas give users actual characteristics — names, faces and narratives. This helps our design studio participants (and our 18F team designers!) shift focus away from meeting specific requirements and deliverables, and onto meeting the needs of the users.
Building user personas
Sketching. Next came rapid rounds of sketching. Participants chose a specific user persona to design for, and each individual was asked to produce 5 sketches in 8 minutes depicting how to meet that user’s needs. After the buzzer told everyone to put their pens down, all participants presented and critiqued each other’s sketches. To do this, we focused on: 1) “Does the design satisfy the goals of the user persona?” and 2) “What assumptions does the design make that we want or need to test?”
Critiquing the first round of sketches
We didn’t focus on whether the design was pretty or technically feasible; we simply wanted to generate ideas we knew would delight our user personas. This process — sketching, presenting, and critiquing — was repeated until the group converged on a clear set of winning designs.
Second round of sketches producing some clear winners!
Exhausted, but excited, the group walked away at the end of the session with clear direction for designs that we can build and then test with real users. Work on this project has just begun, and user-centered design requires more than theorizing. It requires continual testing of our design decisions and assumptions to ensure the needs of users are being met.
18F will also continue to work on this project in the open and in public. That means quickly moving beyond designing for the public to designing with the public.
We’re interested in finding out ways to work with you that go beyond the software code to how the things we’re building actually work. Look out for upcoming opportunities to collaborate! To stay up to date on our work on this project and others, follow us on Twitter.
Getting to work for the American people
Over the last 6 months, 18F has embarked on a mission to transform the way the U.S. Government builds and buys digital services. We’re currently working with more than half a dozen agencies to help them deliver on their missions in a design-centric, agile, open, and data-driven way.
How do we say yes to a project?
We ask ourselves:
- Is there an opportunity to improve the interaction between government and the people it serves?
- Does it align with the 18F core principles of staying focused on user needs while being agile, open, and data-driven?
- Is the partner agency motivated to modernize how they research and build services?
- Does it fit within our project focus areas?
- Does it contain an opportunity to build a cross-government shared platform, service, or module?
Agile development already underway
For our first year, 18F projects focus on:
- Providing cross-functional teams to government agencies, with a focus on user-centered agile product development (Agency Modernization)
- Making government more transparent and accessible to the American people (Open Government)
- Saving government time and money by optimizing internal purchasing processes (Procurement)
- Creating shared tools and platforms to be used by multiple government agencies (Shared Services)
18F’s Current Project List and Innovative Partner Agencies
- MyUSCIS (U.S. Citizenship and Immigration Service)
- MyRA: My Retirement Account (Department of Treasury)
- PeaceCorps.gov (Peace Corps)
- FOIA Modernization (Department of Justice)
- OpenFEC (Federal Election Commission)
- Income Verification Pilot (Department of Treasury)
- U.S. Extractive Industries Transparency Initiative (Department of Interior)
- Common Acquisition Platform Tools (General Services Administration)
- Mirage - OASIS market research tool (General Services Administration)
Attracting great digital talent
The DC team at GSA HQ
Since launching in March 2014, 18F has grown from a small group of Presidential Innovation Fellows into a team of almost 60 designers, developers, product managers, researchers, writers, and specialists. This growth is entirely due to the demand by agencies to work with 18F, as was described above. And we continue to be inspired and amazed by the number of experienced technologists eager to move into public service.
This month, the fall 2014 cohort of Presidential Innovation Fellows also joined 18F, bringing our total number to almost 90. That’s 90 people right now that are collaborating with government agencies to deliver smart, cost effective user-centered digital services. Ninety people who’ve come to us from both government and industry, having worked at the State Department, NASA, NOAA, the Consumer Financial Protection Bureau, Apple, Google, Microsoft, Pivotal Labs, Linden Labs, IDEO, The Washington Post, The New York Times, IndieGogo, Sunlight Foundation, Groupon, and more.
On two coasts and growing
Although 18F is headquartered in Washington, DC at 1800 F Street, we’ve also got a team working in GSA’s 50 UN Plaza in the heart of San Francisco (adjacent to the city’s tech heavy mid-Market area). Twitter, Square, Uber, Zendesk, Yahoo!, and Code for America are nearby. Regardless of where, we work as cross-functional teams dedicated to specific projects that will improve how citizens and businesses interact with government.
Please stay tuned! Follow 18F on our blog, Twitter, or sign up to be notified by email as we share more about these projects in the coming weeks.
Say Hello to the New Presidential Innovation Fellows
The third class of Presidential Innovation Fellows was sworn into duty last week by former CTO Todd Park. We are excited to welcome them into the 18F family.
We recently welcomed the newest group of Presidential Innovation Fellows into the federal government. This diverse group represents some of the nation’s most talented and creative civic-minded innovators.
More than a thousand candidates applied to serve the country in this unique capacity. From this pool of amazing and incredibly motivated applicants, we selected almost 30 designers, developers, entrepreneurs and executives to bring their unique skills into government.
Read the full post at the GSA blog.
Meet the 27 Fellows.
Read more about the projects that make up these initiatives, and the previous successes the program has helped shape.
The Encasement Strategy: On Legacy Systems and the Importance of APIs
By Robert L. Read, PhD with illustrations by Michelle Hertzfeld
In 1986 a nuclear reactor known as Chernobyl released harmful radioactivity which spread over much of the western USSR and Europe. The core of this reactor remains a glowing, ineradicable mass of deadly radioactive lava in the middle of a large Exclusion Zone unfit for human habitation.
The Chernobyl reactor core could not be removed. It was and is too big, too hot, and there is no where for it to go. Instead, it was entombed in a concrete sarcophagus where it will radiate harmlessly for decades if not centuries. This was unfortunately the best outcome that could be achieved. In the software industry, I’ve often seen this same approach used with legacy software systems. I call it The Encasement Strategy.
Legacy systems make everyone that has to touch them queasy, from the software engineers to the managers. But most especially there comes a time when the system no longer serves the most important constituent of all, the customer. This not only contributes to inefficiency, but can sometimes have detrimental effects on the users of a system.
Like Chernobyl, these systems are toxic; but unlike a power plant, what they once produced is not fungible with other sources. There is often no replacement for the legacy system.
The basic mechanism for remediating such a system comes straight out of Computer Programming 101: you create a well-designed interface. In modern terms, this is an Application Programming Interface or API. That term API used to be more general, but now it almost always connotes a web-based interface accessed through HTTP and usually using JSON as its data format.
An API is an inter-face, a face, a façade or a wall between. It allows the user blissful ignorance of what precisely is behind the wall. You need only worry about what comes and goes through the gate. What lies beyond—whether it’s magic, or a red-hot mass of legacy code—is no longer the user’s concern.The customers on the user side of the API are protected from the toxins, leaving the engineers to deal with implementation.
There is something magical about this basic act of defining an interface. To paraphrase Buckminster Fuller, to define is divine. It creates something simple and understandable from nothing, something you can grab onto, something solid.
By defining an API, you can begin to immediately serve the customer, because you can build a modern GUI on top of it, unencumbered by the legacy of the past. You can begin to build what history has shown needs to be built to serve the customer, whether that is the US citizen at large, or a division of an office, or a bureau of an agency. You may choose to allow outsiders to directly make calls to your API, but even if you do not do this, you can create independence of the legacy technology.
Sometimes, such an API can be constructed based on a clear engineering understanding of the internals of the legacy system. This is the best approach; however, it may be impractical if the knowledge and understanding of the system has been lost. In such a case, programmers are wont to resort to reverse engineering solutions, as I did recently. Any system which offers a GUI (graphical user interface) to users can be reverse engineered to construct a programmatic interface on top of that interface. We generally call this scraping the GUI, and it isn’t pretty. It leads to the absurd architectural diagram of a GUI on top of an API on top of a GUI on top of a miasma. But it gets the job done, and that is what a pragmatic software engineer must care about: serving the customer.
Once a valuable API is defined, there is a wall between decisions about how to effectively use the API that completely divorces them from decisions about what to do with the code that implements the API. Efforts to rewrite the legacy system may proceed mostly independent of the efforts to build functionality that uses the API. Or, efforts to rewrite it may not proceed at all—the Encasement Strategy.
As an engineer who loves hard problems, the idea of leaving a legacy system in place and not attempting to rewrite it is a serious challenge. But I think we should always make that decision independent of decisions on how to best serve the customer.
Let us work through a highly contrived thought experiment. Imagine that 100 years from now there is a team of 5 highly skilled specialists, known as Software Conservationists. Their sole job is to maintain the sealed-off core of the legacy system which is STILL implementing an API that serves the US Citizen. Just like Art Conservationists working at the Smithsonian today, future citizens could train to do it.
The Software Conservationists are employed because of two decisions made today:
- a decision to create an API and then—
- a decision not to rewrite the legacy system.
Let us say that it costs $1,000,000 present-day dollars to maintain this team every year from now until the corium in Chernobyl is no longer hot.
How much money would you have to save this year in order to justify paying out an annuity of $1,000,000? Assuming that one could obtain a risk-free 3% after-inflation return on an investment (or, in accounting terms, discount rate of 3%), how much money would you have to save to justify making a decision today that creates the Software Conservationists profession a century from now? The answer is an elementary present value calculation: $34 million or more.
If a realist who is keeping her users top of mind can save the US Taxpayer $34 million today, she should employ the Encasement Strategy and not be ashamed of it. Such a realist should of course recognize the long-term effects of Software Conservation versus the creation of a new, modern system.
Whether the details of your toxic system lead you to begin the legacy rewrite immediately or to employ the Encasement Strategy of delaying the rewrite indefinitely, get started on a well-designed API today.
After this article was published, a kind tweet by David Illsley suggested that this was the Strangler Pattern which Martin Fowler has blogged about. Martin Fowler credits a paper by Chris Stevenson and Andy Pols as the initiator of this idea, and further more references a set of case studies collected by Paul Hammant.
A New Look at the Freedom of Information Act
By Jackie Kazil, Shashank Khandelwal, Raphael Majma, Eric Mill, and Victor Diaz Zapanta
There are many ways the public can get information from the Federal Government. For example, you can check out data.gov to find scores of datasets and APIs, agency websites for information about their work, or other important information in online FOIA Libraries.
Or you can also just ask for it.
Since 1966, the Freedom of Information Act, FOIA, has granted the public the right to access information from the Federal Government. This public right has been maintained for decades and has served as the backbone for information disclosures. This has led to the publication of many important news stories and greater public awareness around government activities.
As demand for information continues to grow, it is important to continue iterating the ways we refine the FOIA request process. Our effort is one of a number of commitments towards creating a more open, transparent government. We will explore how to supplement the work that has already been done by creating tools to improve the online FOIA requests process by designing for the user.
Above: an illustrative prototype running on a mobile device (the logo in the photo is not a live URL)
We are exploring building tools that:
- improve the FOIA request submission experience;
- create a scalable infrastructure for making requests to federal agencies; and
- make it easier for requesters to find records and other information that have already been made available online.
This effort will be conducted with the assistance of a number of agencies and offices within the Federal Government. A FOIA Task Force, which consists of representatives from the Department of Justice, Environmental Protection Agency, the Office of Management and Budget, the Office of Science and Technology Policy, and others, has been created to oversee the creation of these open source software resources.
To reach our goals, the FOIA team at 18F has been meeting with stakeholders, both inside and outside the government, to discuss some of the practical obstacles impeding the current FOIA experience.
As we continue, we look forward to informing you of what we learned, but more importantly we look forward to informing you of what we’re building. We currently have a prototype available of what a consolidated request submission hub could look like. Please follow along at our main FOIA repo, give us feedback or contribute, and look for more updates in the future.
Creating an Open FEC
By Raphael Majma, Sean Herron, Noah Manger, Victor Diaz Zapanta, and Amos Stone
Campaign finance information is not very approachable, even when made available as open data. The laws that regulate how money can be spent around elections are important to our democracy, but sometimes it’s difficult to understand how these laws apply. Between Senate, House, and Presidential campaigns, thousands of people run for office on a regular basis (every two years for the House of Representatives, every six years for the Senate, and every four years for the Presidency). With each election comes a huge collection of information on candidates and political committees, most notably the contributions and expenditures they receive and make. This information can, at times, be difficult to understand, especially without a full understanding of the context of the rules and regulations around how it is collected and monitored.
The good news is that this information is already made available for public use by the Federal Election Commission (FEC). The FEC is a regulatory agency that, among other things, releases campaign finance information. The commission is bipartisan and has long shown a commitment to making sure their actions fairly and equitably disclose important data around certain election activities. This data powers important work by a number of transparency groups, is used by journalists to report on election trends, and informs the public about how money is spent around federal elections.
A few weeks ago, FEC and 18F started to explore how all of this great information can be better presented to the public. Over the past few weeks, we’ve begun learning all we can about the FEC, the process by which it collects and shares data, and how individuals outside of FEC use that data on a regular basis to gain insights into the workings of our democracy.
Users of the FEC website vary in profession and expertise in campaign finance policy and laws, which leads us to consider:
- different formats and presentations
- interactive web presentation or aggregated data as CSV reports
- raw filing data for independent analysis
Creating a solution that will be effective for different use cases is a challenge — exactly the type of challenge that fits what 18F was created for. We’re excited about the opportunity to work on a project of such critical importance to the United States.
We’re still learning about the FEC’s current and future users and will continue working with groups both inside and outside FEC to better understand their needs. We are performing research to better understand FEC’s current audience, as well as the audience they’re not currently reaching. We will test the strengths and weaknesses of our ideas and understanding of the FEC’s website users by developing small-scale prototypes we think will address user needs then let people use and critique these prototypes.
This work, and your input, will directly impact how we and the FEC reimagine their digital presence. Please follow our repository and send us specific requests or ideas through our issue tracker. You can also be bold and provide us a specific approach or implementation idea through a pull request! We can’t wait to work with you to create a more elegant, user friendly, and accessible way to interact with the FEC.
The Contributor’s Guide to 18F: Code for the Common Good
By Robert L. Read, PhD
Transparency in coding makes code more secure. Open-source development is development in the light, sometimes a harsh light, that shows every blemish. At 18F we strongly believe this improves the rapidity of our coding and the quality and security of the code.
We keep the code open to each other, which allows us to quickly scrub in on projects and to dexterously apply the most talented resources to a problem without too much concern for who is formally working on or in charge of a given project. The code is also open to Federal employees from outside 18F and from other agencies. This means that they may both review the code, offers suggestions, and, in some cases, learn from and reuse the code. Just as we reuse open-source code developed outside the government to save money for the US taxpayer, so too do we offer our code to be reused by our teammates, other agencies, other governmental bodies, or citizens and businesses.
The purpose of this guide is to provide some advice on that reuse and sharing, in hopes of fostering it.
All our our code is published and released at GitHub.com under the organization 18F. There you can see all our public repositories (or “repos”). Using only a browser, you can look at any of the code in these repositories, or simply read about the projects. If you wish, you can “follow” a project from beginning to end. Since source code revision systems let you look back in time, you can see the complete history of changes leading up to the current state. Imagine being able to see every draft and edit of Shakespeare’s plays leading up to the publication of the First Folio.
One of the projects we are most proud of and which is highly reusable is FBOpen. FBOpen is a set of open-source tools to help small businesses search for opportunities to work with the U.S. government. FBOpen presents an Application Programming Interface (API) to published Federal contracting opportunities, as well as implementing a beautiful graphical user interface to the same opportunities.
Anyone who wishes to may reuse this code to create their own website, free of charge and unencumbered by obligations. For example, a State could promote economic development within its borders by taking this code, making a slight modification to limit searches to their own State (you would have to be a software engineer to do this, but it is very easy) and then host “Federal Business Opportunities for the Lone Star State.” A business could also build a website using the FBOpen software and API, perhaps even making money by selling advertisements related to the content. The basic idea is that since the software is open source, anyone can use it to build a tool that suits their needs.
Let us imagine that a business has installed FBOpen, changed the name and branding, and is making some money from ad revenue by target marketing to businesses interested in a particular kind of Federal contract, for example cement and concrete masonry. They’ve made some “masonry specific” changes to the code. In doing so, they realize that they have made the code more modular in some way, an improvement that can be shared back to the Federal Government.
Why would they take the time to share this back to the government, when they won’t get paid for it, and it costs them a small amount of time to do so? Beyond altruism, by doing so they keep their codebase as similar to the official Federal codebase as possible. In this way, when improvements to FBOpen are made by 18F, their software engineers can accept these changes with minimal effort. They may decide that they want to stay up-to-date with the FBOpen codebase, and manage only masonry-specific code extensions.
The mechanism for sharing this code back has been worked out and it is relatively simple, as software engineering goes. It is called a pull request, because it is a request or suggestion to the owner of the codebase to accept or “pull” the code change. It is a formal mechanism which makes crystal clear how the code is changing, which is of course critical. 18F will perform strict code review of all such pull requests, and may simply not accept them at all—not every idea is aligned with the codebase owner’s intentions. In general, however, we welcome such pull requests and enhancements. Just as we hope to create opportunities for American business, we can benefit from the creative output of the entrepreneurs and non-commercial software developers. The taxpayers deserve the least expensive, highest-quality software that we can deliver for their tax dollars.
Some Legal Issues
18F is committed to making our code permissively reusable wherever possible. Work performed by Federal employees, such as the staff of 18F, is not subject to copyright and is in the public domain within the US. However, we use a copyright waiver for other jurisdictions to clarify matters and ensure unrestricted public use outside of the US.
Even though it is our intention to release all code permissively, you may find a derived work of someone else’s code in our repositories. In order to save the taxpayer money, we reuse work that others have created when possible. An example of such a file is pycas.py which is part of the PriceHistory project which was begun by Presidential Innovation Fellows and is now maintained by 18F. This individual file is Copyright Jon Rifkin, 2011, and it was reused and modified as allowed by the Apache License 2.0 under which Mr. Rifkin released it. This file remains copyrighted by Jon Rifkin and covered by the Apache License 2.0.
Since similar situations may arise in any repository, check the individual README and LICENSE files for each project on GitHub for details specific to that project in order to reuse our code legally—which we strongly encourage!
GSA is not permitted to accept voluntary services or ask people to perform work on open-source projects free of charge. However, since our open-source software projects are available in public repositories for anyone to learn from or reuse, individuals may decide to improve the software for the benefit of others or offer suggestions to improve the code.
In general, individuals who choose to contribute to an open-source project do so without the expectation of payment. There are a variety of reasons why software developers elect to contribute to any open-source software project. The reasons include:
- Desire to make an improvement to software that a programmer is using;
- Demonstrating one’s commitment, talent, and experience;
In the case of our repositories, there are several kinds of contributions:
- Report bugs, ideas, requests for features by creating “Issues” at GitHub in our project repositories. An issue that begins “Have you thought of…” could save a project months of labor.
- Fork our code and play with it, whether you later choose to make a pull request or not.
- Create pull requests of changes that you think are laudatory. From typos to major design flaws, you will find a target-rich environment for improvements.
Working In Public From Day 1
By Eric Mill
In the wide world of software, maybe you’ve heard someone say this, or maybe you’ve said it yourself: "I’ll open source it after I clean up the code; it’s a mess right now."
Or: "I think there are some passwords in there; I’ll get around to cleaning it out at some point."
Or simply: "No way, it’s just too embarrassing."
These feelings are totally natural, but keep a lot of good work closed that could easily have been open. The trick to avoiding this is simple: open source your code from day 1. Don’t wait for a milestone, don’t wait for it to be stable — do it from the first commit.
Here are a few reasons why you should feel good about working in the open from the moment your shovel goes in the ground:
No one’s going to read your code. Your code is almost certainly boring. Most code is. Instead, people will evaluate your work based on how they’d interact with it. Is it easy to learn how to use it from the README? Is development active? Have many GitHub users starred it? And none of that will matter until your project is far enough along that it’s useful. You will not be in the spotlight until you deserve to be.
You will make better decisions. At the most basic level, you will be vastly less likely to accidentally commit a password to an open source project than a closed one. But more than that: even though no one is reading your code, you’ll still feel a bit of natural pressure to make better decisions. You’ll hardcode less, and move more into configuration files. You’ll make things slightly more modular. You’ll comment more. You’ll catch security holes more quickly. That’s a healthy pressure.
It will not waste your time. It may feel like some of those “better decisions” take more time. But even if you’re the only person who will ever work on this project, you have to live there. You’ll greatly and immediately appreciate having made those decisions the minute you return to your own code after taking a month off. And when making better decisions becomes routine, they stop taking more time — and you become a better coder.
You might just help people. And people might just help you! The internet is a big place and a small world, and GitHub has a way of making unexpected connections. If your work is even a little bit useful to someone else, there’s a good chance they’ll find their way to your door, start poking around, and find a way to be useful right back. Even if you’re working on what you think is the most niche project that no one else would ever use: leave the door open for providence.
Once you get used to beginning your work in public, it stops feeling like performance art and starts feeling like breathing. It’s a healthy routine that produces better work and personal growth, and opens the door to spontaneous contribution and engagement. When your default is open, everyone wins.