Software Development Team Request For Proposal
Canonizer seeks to contract with a software development team of 4 or 5 full time engineers to help convert the current prototype system at Canonizer.com to an open source, fully developed, fully automatically tested and deployable product that can scale to handle millions of simultaneous users. We need a team that can continue the development of the open source Canonizer.2.0 system
, currently using LAMPS with the Laravel framework.
Canonizer plans to become the Wikipedia of thought and opinion on controversial issues. We are going to bring the world together by building and tracking consensus on moral topics.
As you prepare your proposals please consider the following:
- Currently the system is running on a single AWS EC2 instance. This can only handle a small number of users at a time without significant performance degradation. A system needs to be designed that enables the system to expand to new instances, and contract, as needed to handle any load.
- Help us re-architect and help implement and convert to a new text editing and management system module. The current wiki markup is cumbersome with inconsistent formatting. “Ease of use” being of utmost importance, so UI design abilities are important. This includes a powerful version comparison tool to replace this does nothing version page so people can easily comprehend the diffs between version.
- Where possible support the open source community. If there is open source code we can leverage, let’s leverage that, possibly returning contributions to that community or else architect open source modules others can use.
- Help finish the design of and conversion to a fully test driven development system, with 100% automated tests and deployment to enable continuous release process.
- Help prioritize tasks and perform team code reviews of all new development.
- Convert the system to a service oriented architecture, starting with the creation of a new “canonizer” service. This service may be built on something other than LAMPs, with cpu efficiency being of primary importance, since this will be doing most of the canonization computation. Design an API which can provide a topic num, an asof value, and a canonizer id. Given that, it will return a JSON tree structure of camps and supporters of that topic, decorated with canonized scores of the selected canonizer ids, which can then be rendered on topic pages, or called by third parties. We eventually want to provide users the ability to program their own canonizer algorithms, so a design towards making this easy for users is important.
The budget for this job will start at $100K per month or more than $1 million / year, on an ongoing basis, depending on the quality of, and amount of work being done. We intend on hiring one or more companies to help with this project, depending on expertise and abilities.
The goal of Canonizer is to be a leaderless organization where everyone knows everything. Any software development company interested in applying for this job is invited to create a sub camp, with a camp statement describing how their company is the best company for the job. Then the canonizer canonizer
algorithm will be used to select the top candidate. Currently, some of the primary share holders are already supporting the Agreement Camp, where you can see their canonized share score. Eventually these supporters will be ranking their camps, in their current preferred order, which may continually change till selections are made. Candidates are also encouraged to support their own camps, as their top choice, and all competing candidates, in the order they think is the best candidate to achieve the Canonizer goal of bringing the world together.
There is a lot to learn about this canonization, consensus building process, which we hope you will learn and use to be voted and selected as the top candidate. Each camp has a “forum”, where questions can be raised. So if you have any issues our questions, everyone can go to the main Agreement Camp for the job topic
, then go to the forum, and submit your questions for everyone to see. You can also solicit collaboration from other interested parties, while building consensus for the scaling design in a super camp, and so on.
Qualified teams that respond to this RFP may be eligible to receive payment for the time required to study and learn about the Canonizer process. You can reach out to firstname.lastname@example.org and ask to meet with the primary shareholders to negotiate compensation for this development process.
You could answer at least the following questions in your camp statement:
- How would you architect a canonizer to be massively scalable? It needs to be able to automatically grow, when needed, to handle millions of simultaneous users, then scale back to save costs when load is absent. This is particularly difficult given the real time nature of the canonizer process used to display each topic, currently being done in real time, part of why the system is slow. Each time a topic is displayed, you need to iterate on each camp C * iterate on each supporter S * perform the canonizer algorithm for each person A * for some topics repeat this entire process on yet another topic, resulting in a current speed of C * S * A partial (C * S * A) all given any “as of” date either current or at any time in the past. For more information see this “ peer ranked” canonizer algorithm information.
- You will get extra credit if you collaborate with others competing for this position to build consensus around and collaboratively develop a design, possibly creating a supper camp multiple competing camps can support, showing your support for that scalable software design as it is being collaboratively developed. If you are late to the game, and others competing for this position have already developed and are supporting a good design, you may just choose to move your camp into a supporting sub camp position of that design, indicating you think it is the best design. Of course, any additional contribution to improve any existing design camp will be to your credit. And if there are any existing proposals for which you disagree are the best, you can start a new supporting sub camp with the proposal you think is better.
- What type of team management or prioritization tools are normally used, if any?
- What is your philosophy on code reviews by team members, or strategies such as team or pair coding?
- What experience do you have setting up and maintaining systems that are 100% continuous delivery enabled, including automated tests that prove 100% of functionality still works with each modification made to the code, along with automatic deployment of such fully tested changes
- Provide any other ideas of how you could contribute or help improve Canonizer and it’s goals.
- Do you have any examples of times when you went beyond what was being asked of you by your immediate supervisor to further the goals of the company or humanity as a whole?
This recruiting process is expected to take multiple months to find the best company. We are a global team so it doesn’t matter where in the world the engineers are located, we only ask that you be flexible with meeting or daily standup times.
To Do List
, with Iffort
, proposed putting out some tasks that teams could get started on. So here are a few possibilities:
- Potential Security Vulnerabilities being reported in Github. As you can see from this link, Github is reporting this issue. Our engineers have started considering the work required to update our system to current library versions, in order to get these issues fixed, but we haven’t yet had the time required to get this high priority issue resolved, yet.
- There is a boat load of open issues for that repository. If you see one on that list that you’d like to tackle, that’d be great. Just let us know which one you’d like to get started on, so we can make sure someone isn’t already working on that one. The ones with the “21st Release” tag are being currently worked on for the next release.
There are instructions on how to set up and build a development version of Canonizer in the project’s main README.md file.