Adding Your Project to Our Portfolio
Do you have an open source Flutter or Dart package? Would you like for companies to fund further development? Would your package make sense within the Flutter Bounty Hunters portfolio? If so, let’s talk!
The Flutter Bounty Hunters is a remote team of Flutter and Dart developers who work exclusively on open source packages. We find companies that need infrastructure tools, and then we work with those companies to setup funding, and build what they need.
Usually, we create our own projects from scratch. But there’s no need to start from scratch if you’ve already done great work on a package that solves the same problems!
If your project solves a problem that’s relevant to the direction of the Flutter Bounty Hunters, we’d like to bring your project into our portfolio, and then work to find companies that will fund further development.
How to transfer a project
If you’d like add your project to our portfolio, let’s jump on a call to chat about expectations. If everything looks good after our chat, then you should expect to make the following adjustments:
- Transfer the GitHub repo to the Flutter Bounty Hunters organization.
- Transfer the Pub release to the Flutter Bounty Hunters organization.
- Change the LICENSE to an MIT-style license, because it’s the most flexible license available.
- We’ll design a logo and README file to match other Flutter Bounty Hunters projects.
After migrating your project to the Flutter Bounty Hunters, you’re welcome to include your name in the README as the person who started the project.
How to build with the Flutter Bounty Hunters
The Flutter Bounty Hunters uphold a set of coding standards. With paying clients, we need to ensure that the right problems are solved, they’re solved effectively, and the solutions are well tested to ensure that we don’t break them in the future.
We welcome continued contributions from the original project authors. However, all contributors, including the original authors, are expected to comply with the Flutter Bounty Hunters policies, and quality standards. Some such policies include…
- Team discussion of complicated changes, and breaking changes, before spending time on a PR to make the changes.
- Dart docs included for every public member. Each Dart doc should effectively communicate the details that aren’t obvious when reading the code.
- Effective tests for all contributions.
- Code review for all changes.
If all of this sounds good, then we look forward to working with you!