DBGrow Inc

David Chapman

Factomize
Thank you for the application.

A. You have an impressive list of projects you would like to develop. With a 50% Efficiency, is your team's plan to continue to work on those projects part time and hold down regular jobs?
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
Thank you for the application.

A. You have an impressive list of projects you would like to develop. With a 50% Efficiency, is your team's plan to continue to work on those projects part time and hold down regular jobs?
Hello,

Devon and Julian will both dedicate their full time and priorities to DBGrow, which has transitioned to an exclusively Factom technology development company.

Sebastian is currently finalizing his team’s research project at Lawrence Berkeley National Laboratory (LBNL) for submission to Proceedings of the National Academy of Science while beginning to work at DBGrow. After publishing his current project, he will continue to have limited and flexible responsibilities at LBNL, but will be working at DBGrow full time.

Spencer will be working at DBGrow on a part-time basis. He holds a job at a Google funded data analytics firm that has flexible hours, flexible IP assignment, and remote work policies. His role at this company will continue to bring new opportunities and connections for DBGrow in the enterprise software space.

While 50% efficiency could raise concern of financial constraints in the event of M3 revenue fluctuations, we have extensively modeled DBGrow’s financial proceedings and feel comfortable moving forward at this level of efficiency with our given project roadmap.

We also believe the developments we are achieving will allow us to secure grants in the future to expand our project development. Regardless of such grants, we have the ability to self fund any development costs beyond M3 revenue, and we believe that our time invested into DBGrow will lead to a sustainable company in the long run.
 

David Chapman

Factomize
C. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you also discuss additional development work which is important despite your node Efficiency of 50%. The Standing Parties will likely want to see what progress you're making since it was part of your campaign. My questions are:

1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
2. What would you communicate and how often?
3. What metrics should be used to gauge your development progress and success?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Thank you for your application

NK01)
In your application form you state that there are 3 team members with 15 years of experience running servers. Could you break that down for me and only listing production server administration?
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
C. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you also discuss additional development work which is important despite your node Efficiency of 50%. The Standing Parties will likely want to see what progress you're making since it was part of your campaign. My questions are:

1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
2. What would you communicate and how often?
3. What metrics should be used to gauge your development progress and success?
1.
We currently are compiling what will become a public trello for tracking our teams development, developer relations, and promotional progress in real time according to a SCRUM workflow. The Factom community will be able monitor our SCRUM board with up to date milestones, feature priorities, and time estimates. This allows transparency for shorter term development goals, and ensures that any changes to our features or time estimates are fully documented and transparent.

All our current software development is open source on Github. Developments will correspond to commits and progress in our open-source repositories, which may also serve as a forum for community input and collaboration.

2.
We will release monthly updates that we will host on our website with links from our trello, and the Factom Discord. DBGrow will also look to involve the Factom developer community in testing and using our projects, and this will serve to help verify development and increase the usability of our projects.

3.
It will be easier to gauge the progress of our short term projects and alpha releases, as they will have shorter and well defined metrics to gauge according to our SCRUM workflow. Our longer term projects that involve a larger degree of exploration and research work are more difficult to quantify success in the short-term. This is part of the reason we aimed for high efficiency, and targeting more grant proposals in the long run, even given our large aspirations for development. While research work cannot easily be quantified, our development projects will have well defined release goals once the bulk of the research phases are complete, and these goals can be laid out in a transparent and accountable way within a grant proposal.
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
Thank you for your application

NK01)
In your application form you state that there are 3 team members with 15 years of experience running servers. Could you break that down for me and only listing production server administration?
Hi,

All 4 members of DBGrow have experience running servers, but only 3 will work as regular server admins. We have determined that Spencer's time is best used filling other roles for DBGrow.

The following describes the time we would consider having run “production” servers that required a high level of security and uptime. We have spent a similar amount of time running what might be considered “development” servers, mostly for scientific and application development purposes.

Devon:
Devon has been running production server and database clusters on AWS since 2015 (NodeJS, MongoDB, Redis, running on top of Ubuntu). 2 years running the MsgFly application server cluster, a chat/messaging SDK and backend service on AWS. 1 year running and administering dbgrow.com & it’s collection of currently 25+ production databases spread across AWS.

Sebastian:
Around 8 years administering OpenSSH and OpenVPN servers on Linux/Windows/Android at research institutions to enable remote access to scientific files, simulation systems(such as Molecular Dynamics), and networked scientific devices (HPLC and Fluorimetry systems).

Administration of the rebeltext.org academic resource website for about 6 years. Contains materials for economics courses for a number of major US universities, accessed by several thousand people each month. Provided support for functionality to add materials, make those accessible across a range of devices, and index them according rebeltext’s house built QR-redirect system.

Julian:
1 Year running production profiling and data analytics servers on MsgFly’s text analysis platform. 1 year general server administration at DBGrow.

Spencer:
2 years running onsite server rendering farm at Diablo Valley College. Ran and administered 5 Autodesk Backburner servers on Ubuntu OS to handle student workloads.
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
NK02)

Could you elaborate a little?
DBGrow launches bastion instances through our AWS dashboard to administer our servers when needed, and then terminates them as soon as maintenance is completed. At any given time, a point of SSH access to our internal network exists only if maintenance is being carried out by a team member with proper AWS privileges, SSH access keys, and 2FA.

This affords some security advantages over a traditional persistent bastion host:
  • There is no persistent point of access to our network to attack
  • Any bastions spun up for SSH access use a new public IP address pulled from AWS’s pool each time. This makes the bastion more difficult to find and attack.
  • Any bastions spun up use the same standard OS image for every launch(Includes fail2ban and 2FA).
  • Bastions have no persistent storage. Information from past logins cannot be accessed because they are not persisted (forwarded keys, keystrokes, logs, etc).

In the event of an AWS outage that prevents us from launching new EC2 instances to serve as bastions, we will attempt to configure other points of access such as VPN gateways or solutions based on AWS Systems Manager.
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
NK03)
Will your team be working full time? If not could you break it down
Devon and Julian will be working full-time from the start. Sebastian will be transitioning from part to full time over the course of his current research winding down, and Spencer will stay at part-time for the foreseeable future. Thread post #5 describes this in more detail.
 

Julian Fletcher-Taylor

DBGrow
Exchange Working Group
Legal Working Group
NK04)
You will be only taking a small amount of FCT initially. How about the salaries of your team members?
Through Q2 we will only be liquidating what would cover a full tax obligation, 28% of what’s left after the 50% deferment, and from there on will reevaluate our necessary liquidation. In the meantime, necessary salaries will be paid out of our initial 50,000 USD funding for DBGrow from founders.

Our Financial Continuity plan describes some minimum salary situations, and these minimum salaries are what DBGrow would be looking to give the first couple of months. We have been advised to pay minimum wages for work done that is required by DBGrow, and minimum exempt employee wages under CA law for employees of DBGrow that are required by the company to be on call 24/7.

We would eventually look to transition these salaries to full competitive salaries for our work, but we are in no rush, and plan to do so in a slow and responsible manner (it’s easier to slowly grow salaries than have to cut back salaries once expanded if M3 Revenue falls). Developing DBGrow into a substantial long-term company that will have large impacts on both the Factom ecosystem as well our scientific domains will always be our priority.

An important note also is that this describes what DBGrow can assure as a company in its current state. All members of our team plan on continuing work in the same capacity as described throughout our documents using our personal time regardless of whether or not DBGrow can pay our salaries. We are not averse to self funding development that we believe will be impactful in the long run, and we believe our projects will be.
 
Top