The Code Market
built on eosio
v2.2.4 - 2018-07-31
Nowadays, when humans are united by common goals and interests more than by territorial or some other casted dependencies, the role of states acting as centralised administrators diminishes, and causes the worry to a handful of rulers, who most often, as a rule, possess just personal interests in maintaining the power.
Once upon a time the aim of the State was a common good of its citizens. The human draw towards egoism and the natural instinct of survival to be superior and more advanced than any other individual, the constant fight for a place under the Sun has been grown into our blood since being animals, caused and encouraged not only a game without rules and an all-around progress, it also crumbled and diminished the concept of common good as the idea of common goal.
If you realise today's technological possibilities in uniting humans into autonomic decentralized communities, the power of such communities, and if you have ever felt your hair rising from an excitement, then you know how we are excited to invite you to join us on the front row, not only to observe, but also to build a way together towards the common goal.
Currently, all cloud based source code repositories and distribution is handled by privately maintained profit oriented companies like Github (by Github Inc., USA), Bitbucket (by Atlassian Pty.Ltd./Inc., Australia), GitLab (by GitLab B.V., originated in Ukraine but rebased to USA), Launchpad (by Canonical Ltd., UK), and many others. Most of them are even proprietary code based, while SourceForge, which is in decline and has already the 3rd owner, is the only major open source player. This leaves basically all global developer community with having their code repositories serviced by privately owned, profit oriented organizations and closed source infrastructure, while most of them are all based on open source git code repository backend. While both Github and Bitbucket offers free to use options for open source code repositories (bitbucket even offers free plan for micro proprietary code developer teams), proprietary code repositories need a constant paid subscription to be online. Even worse - proprietary code repositories silently are carrying the infrastructure costs of open source code repositories. While this may seem altruistic from such organizations and open source community supposedly should feel grateful, the aspect of centralized control to which community has no voice and that the future is unknown are both apparent.
The question of security and persistence is also valid here. Any repository on, let’s say Github, is alive only until Github is online. If Github fails or goes down forever, the repository with it goes as well. OK, due to distributed nature of git the code will stay on local machines of developers and ones who cloned it, but further collaborative work on it won’t be possible without a new centrally hosted code repository. How it affects related repositories which use it as dependencies? Catastrophically because of URL dependency and manual intervention necessary. Hosting, serving and managing code repository through blockchain is the answer, as the persistence of the repository becomes basically eternal.
Furthermore, the fact of existence of the code in private code repositories is basically void to the World of developers except for its owners, maintainers and developers who work with such code. This leads to perpetual “reinvention of the wheel” over and over again instead of improving the already existing “wheels” more collaboratively. Competition also exists in the open source world, but also does collaboration and reusability. Currently software development market is undersupplied, and in a such inefficient way that everyone is solving the same problem in over-competitive manner and perpetually wasting time. And this mostly happens just because such private projects and thus private code repositories are not discoverable by any means. Nobody can buy and reuse the unknown.
Blockchain infrastructure based git code repository service with public metadata and secure smart contract licensing. Instead of depending on financially and organizationally vulnerable centralized infrastructure, where centralized owner can make decisions over the community code and dictate terms, the infrastructure is transferred to the DAC - Decentralized Autonomous Community itself. Initially, all produced content going through git and the blockchain will be hashed and checksummed, where these hashes and checksums will be screened against everything it is know, and as metadata collected and stored in the blockchain. Also, URLs for accessing secure git storage providers would be stored on blockchain as well, making the dependency inclusion aspect solved even if physical code hosting would be moved or would go out of service. Once the solution is found to do it securely, the code repositories will be encrypted and stored in the blockchain controlled IPFS. Commits entered into repository will remain forever as long as network lives, unlike corporate entity dependent alternatives we have now. By utilizing the DPOS (Delegated Proof of Stake) Blockchain 3.0, infrastructure participants will earn their fair share for delegating their resources to the community infrastructure.
As in current commercial implementation of existing code repository services, public open source code co-exists with private proprietary code in the same infrastructure. Transactions are processed and their volume depends on delegated stake user has in the blockchain infrastructure. Open source code repositories and their developers will need to be staked to be served, especially when considering a zero resource starting balance. It is possible to allocate minimum viable resources by blockchain consensus to every project or developer in a way that it is enough to start and at the same time it cannot be abused too much to slow down the network. At the time of writing this feature is not yet implemented in EOS. When growing, in such a way, open source developers are also motivated to have a part of the network, as they are contributing to the infrastructure they are using themselves, plus they are getting the financial benefit for serving the commercial proprietary codebase, and can have a stake in the grand picture.
By adding the publication capability of the metadata and taxonomy for the private code repositories, codum also provides the so missing visibility feature for the proprietary code - the value of discoverability:
- For owners of the code: ability to source and profit from the code by licensing it under smart contracts at any stage of the code lifecycle.
- For developers of the code: added value to the work history and profile, and ability to save valuable development time by discovering and outsourcing the existing code from other private repositories in addition to what is available in the open source.
- Both sides benefit from wider code reusability and easier integrations naturally happening due to the fact that larger and larger parts of code become common across their projects, making projects to be developed faster while reducing the maintenance costs and shifting the responsibility.
All the transactions are formalized in the smart contracts between the parties.
Licensed forks of private repositories may never become open source without the decision of the owner of the parent private repository, while the minimal metadata of such repository would be public without an option. This enables the accounting of chain forking and cloning added to such metadata of all repositories.
Code theft detection is integrated in codum as well: in case cloned/forked repository content appears in the network as a new repository by at least some part, both owners are notified of each other. Such checks are performed by the blockchain infrastructure knife nodes where finders are rewarded from the revenue share.
Additional values are provided by creating the integrated project management, developer sourcing and market capabilities to the system. Developers gather their portfolio profiles by participating in the projects, both open and proprietary, where such profile data can be used for developer candidate selection process within the system. Employment can then be formalized as a smart contract and payment processed on acceptance merger. Also, both contract sides - the developer and the contractor - can rate each other and the rating weight will depend on the smart contract overall value, on top of the success rating gathered from the metadata of the related developments, including such data as estimate overshots, declined pull requests, failed tests and so on.
On top of that all good, software development driven token emerges, together with this newly created development and licensing economy. As software development services are higher in demand than supply, and when developers are taking codum token as preferred way of payment because it comes with the assurance and profile value for executing the smart contract, codum starts to gain momentum in valuation related to other crypto and fiat currencies, driving all cryptocurrency economy upwards. Companies need software development services and will want to exchange fiat currency into codum to pay developers. Additionally, software licensed through codum will gain demand in mass of the software consumer market with time, becoming the standard in software licensing.
Public Website Frontend
- Representative content explaining the codum platform - what it is and how it works
- Platform services and user benefits
- Account Management interface
- Registration for Users and Organizations
- Profile Editing and Statistics
- Account Access Management
- Wallet and Smart Contract Management
- Project Management interface
- Code Management interface
- Infrastructure Management interface
- Pricing calculated based on real market data
- Account Management interface
- Interblockchain (EOS, Steem, Ethereum, Bitcoin, other altcoins and tokens considered)
- Centralized (Google, Github, Facebook, Linkedin, Twitter, etc.)
Source Code Repository Management Frontend
Essential functionality for browsing source code repositories like in Github. Including, but not limiting to essential code review and collaboration functionality, served with a different and enhanced User Interface with seamless integration of Project Management with Agile Boards, Task backlog, states, time tracking and insights. In addition to that, it will be fully mobile friendly and operable at all levels - allowing all collaborators to have full control of the situation on the go: from manager being able to redistribute tasks and check on overall progress across the projects, down to developer being able to make a quick fix and see if it builds, and then deploy it.
Open Source Code Repositories
All registered and anonymous users are able to see and get everything - source code of all branches, builds, releases, commits, pull requests, related issues in the project management board, and all related entities. Registered users can participate in all development process of public/open source code repositories - fork, code, commit, push and submit a pull request. However, integrated task management helps to easier track progress and assign commits to tasks even after their submission, so it will never be too late to add that comment to commit message.
Owner of the repository is the de-facto moderator/maintainer of the repository as well and is responsible for its content and licensing. However, such roles can be redelegated. Multisignature smart contracts integrate on all levels of codum functionality.
Cloning and forking is not restricted for open source code repositories, however, distribution and derivatives can be enforced by the license if owner/maintainer decides so. Initially it is planned to implement and support GPL 3.0, MIT, BSD, Apache 2.0 license smart contracts.
Private/proprietary Source Code Repositories
These work differently than it is implemented now in Github or Bitbucket. The owner of the repository is the user who decides what level of metadata is publically accessible, and what is not. The owner also can delegate responsibility and access to other users or user groups, and roles and access groups logic is shared between code repository and project management functionality.
Pricing is as flexible and as enabling as it can be thanks to DPOS and Smart Contracts. Private code repository owner is paying not a user headcount (participating staff and developers) or repository number based monthly subscription. The owner is only being charged in real time for network resources utilized related to the source code repository in question.
The so missing feature in existing private code repository services. It includes the following data and publication of each position is optional unless Licensing is enforced by Smart Contracts:
- Repository name, repository owner/maintainer users and participating users
- Public readme file of choice (most text formats supported)
- Human readable ricardian Licence Smart Contract
- Technical git metadata (branches, commit hashes, commit checksums, file checksums).
Licensing of the source code repository becomes available with the above mentioned Public Metadata feature. Once licensing is enabled, for it to work, all Public Metadata features must be enabled on the proprietary code project. Due to proprietary nature of such repositories, they cannot be used in open source projects even as dependencies unless the Owner’s repository becomes fully public/open source - the dependency links still can be made but submodule functionality will just not work if user does not possess the License Key to the repository. Licensed repositories will only be able to be accessed via SSH private/public key pair authentication where public key is also a part of the smart contract.
Initially Planned Smart Contract License Templates
Accounts for “use only” case of license, where Client is entitled to clone the repository for the License fee agreed by the Smart Contract between the Owner and the Client, where Client is granted the Clone Key Certificate. It is SSH security key which entitles the Client read access to the licensed code repository branches and commits. Multiple pricing options are available:
Each `git clone` action is charged to the Client a full license fee, while `git pull` action is charged to the Client the update fee, but only in case the commit is newer than the one stamped on the license. All current or older `git pull` or `git checkout` actions are not charged. `git fetch` is free of charge all the time.
Each `git clone` action is charged to the Client a full license fee, while `git pull` action is free of charge for the subscription period. If subscription is expired and not renewed, it becomes Branch/Commit Limit Clone License stamped with the latest commits before the expiration timestamp.
Clone Redistribution License
Enables the Client to include the licensed repository as a dependency to his proprietary source code as git submodule. The Distributor then receives the Redistribution Key Certificate for the repository, which can be used to access the repository by chain. the Owner of the licensed repository receives the benefit of Licensing to his code where perpetual Clone Licenses are issued on demand.
Enables forking of the repository, where the Client is granted the right to source code derivatives and further redistribution, thus creating the possibility for the Client to participate in the development process. However, Client and Owner must agree on redistribution, intellectual property and other terms. It is possible to set the Client free of obligations as well as restrict it to any physically definable bounding limitations.
Pay per Merge
Each merger from upstream is charged the update fee to the client in case there are physical changes in the repository
enables unlimited mergers from upstream for the defined subscription period in the Smart Contact.
Contracted Developer’s Forking
It is a special license issued to the contracted developer with the ability to gain read access to the project and ability to fork the repository. However, such license strictly limits the redistribution, including derivatives. Furthermore, the developer with all related contact circles are the first targets of the Knife - so called unlicensed redistribution guard algorithm.
Pull Request Smart Contract
Enables the Client’s developers to contribute to the Owner’s project and even get paid for it. Issued Pull Request appears on the Owner’s repository (changelog, documentation, changed files and lines and the price). The owner can, from that moment, pull the changes, build and test the submitted code, etc. However, the Owner is not holding any rights to the contributed content before merging the pull request, or fulfilling the smart contract. Knife will work on the benefit of unaccepted/unfulfilled pull request contracts in case such content appears magically in the Owner’s code repository. When the Owner accepts Pull Request, the Client is getting paid for the contribution. If PR submitted content later appears in the Owner’s repository, the Client has a right of compensation and financial obligation of the PR Smart Contract may be executed fully or in parts depending on the situation, and in case defined details in the smart contract are enough to do so, it will be done automatically and immediately.
Knife - protection against unauthorized distribution, license violations and theft
“Because it has to be served with the fork”
Blockchain infrastructure providers, motivated by an additional reward opportunity, will be running the bounty hunting Knife operations - theft protection algorithm for code repository owners to enforce licensing terms. The Knife will run on codum Knife nodes and will check everything against everything as long as codum infrastructure is sufficiently staked on EOS. Lack of stake, on other hand, would reduce the volume but not pause the contract - as soon as resources are enough, Knife will continue at full capacity. The algorithm running on the infrastructure Knife nodes compares the metadata of the existing and newly uploaded content or it’s changes to the metadata of any other repositories known to the network. In case a match is found, both parties (owners of the repositories) are informed of each other. In case of Licence breach, the repository containing the suspected unlicensed content is suspended from any commercial/licensing operations before the parties resolve the issue, the Owner discards the claim, or no-response timeout happens which is relatively short. The contract is automatically recurring and gets suspended only when there are no more unchecked commits left. The Knife contract is changed from search mode to listen mode. In search mode, the bounty contract is comparing the licensed content to everything is known in the blockchain. In listen mode, everything coming to the blockchain is compared against the licensed content.
System Imposed Knife limitations
There will be cases where codum licensing and real world intellectual ownership of non-material property will clash, especially in the early days of codum life. The process of solving such legal issues is well thought through and the solution exists. There are many ways to separate genuinely developed project from archived dump of source code and this will be taken into account. For example, source code repositories forked from other git sources into git, or otherwise having a development history, will have more rightful weight against file dump after git init into a fresh source code repository. There will be also a way to link existing Github, Bitbucket and other 3rd party provider accounts and prove the authenticity. With these mentioned information sources, the owner and the violator can be distinguished inside the system trustlessly without any human input. In all other cases, where manual decision and legal process will take place, the real source code owner has what to show for it, and is an active maintainer of such code base, sporting the knowledge of most recent issues. The only problem we might have is contract IP infringements of the developers to their customers, and even these partly can be solved by above means, or manually by processing related documentation. In general, such issues would be relevant only at the very beginning where source code would be developed outside the codum development environment, and will be lived out with time.
At the later stage of codum project, Knife Crawler will be created, performing search engine crawling services across all known publicly hosted git source code repositories and collecting minimum viable public metadata on their content. This would be done in order to protect both sides from license and IP (intellectual property) violations. Git providers, blocking the crawler, would be considered outright violators and legal actions would be taken to enforce the access. On other hand, the crawler would be operations could be arranged through robots.txt file of the provider’s site, declaring traffic limitations and optimal off-peak hours for doing the crawl, however, both hours and traffic limitations cannot be above 10% of the provider’s capability. Also, crawler would be operating using git protocol and would never redownload unless integrity of the known repository is compromised, thus saving the provider’s resources.
Project management frontend
Setting up a project - creating and running the board, task backlog, workflows and development processes, roles and rules for developers, time logs and code delivery performance tracking, issues and reviews - all of that every software project needs and what is Project Manager’s primary responsibility. The ability to execute and run everything close to the source code repository is the key to success for the project owners and managers - as it is running the project all in one place, compared to multitasking across a handful of software. The ability to handle Client and Customer relationships and communication, connecting the issue tracker and backlog, eliminates a lot of misunderstanding and eliminating transparency issues greatly improves project’s performance.
Business Use Case - assemble the team for your project
As a business manager, you just simply create and fund your account personal, create a project and describe what it is about. Project can have its own balance account, or project can be funded directly from project owner’s account. When the project is published the project’s CTO decision must be taken, where CTO can be hired, delegated or project owner can take it on it’s own. In all cases the project’s CTO role, indifferently from any other founding/board team members from technical perspective, is set up as a smart contract defining responsibilities and rewards, and these can be set up once they are necessary. In case project owner has no technical person available to take the CTO position, codum system can suggest, depending on keywords used in the project’s description, from the global pool of currently not engaged in projects, experienced in project management users. At the same time, such users will see this project in their project opportunities board, where they can bid their offers to the project owner.
Established infrastructure of source code management and distribution together with project management and internal token driven economy creates the perfect space for one more component in the system - software developer sourcing. And most of the components and infrastructure are already up in place. We have published private project metadata, tasks and code access licensing. And we can implement a chain of smart contracts for executing the developer sourcing.
CTO breaks down the project into components and tasks. Development methodology here is open and any of them can be adopted, be it lean, agile, waterfall - you name it. Job offer and the issue or task in the backlog is one and the same thing. Then, developers can be sourced through the codum in a similar way CTO was sourced:
- CTO and the project owner will see the available candidate suggestions depending on their experience in similar past tasks, and developers themselves will have opportunity task lists which they can bid to work on.
- Developers bid their offers to execute the project with their set hiring conditions and estimates. Developer decides payment terms, but CTO can negotiate it, or CTO sets them on tasks right on their creation.
- Once the arrangement between parties is made, it is formalized as a development sourcing smart contract with all conditions, like specification, quality guidelines, rules, terms, deadlines, payment terms and so on included and enforced by such smart contract.
- Conditions agreed on and signed as a Smart Contract become binding.
CTO also makes decision on the workflow with the code repository, either giving permissions to the repository branches for each task, or allowing developers to fork the repository for themselves and submit a pull request to designated branch. In any case, the merge operation must be performed as an acceptance proof and resolution for both sides.
- In case code repository is private, during the employment time the developer gets Contracted Developer’s Forking license to the private repository in case of fork-PR workflow. Otherwise - clone license.
- Developer, in the process of the developments, submits his Pull Request with contract of acceptance, which also has binding implications to the Employer/CTO/PO. Even if PR was not ever accepted but the content was recreated, the developer has a right to the compensation.
Ranking, rating and reputation
KYC is required for all users of the system - customers, developers, arbitrators. All EOS/codum accounts will need to get approved manually, but this process is to be automated when reliable 3rd party KYC solution is found. There will be no codum holders using any codum service with unapproved eos account.
Developers build their experience and profile with every commit they perform in the system. That includes work on private repositories with published metadata. At the same time, repository owners can showcase their developments at any stage once the metadata of their private code is public.
Rank would be the representation of the weight of total developments performed or owned by the user. Participation is rewarded with rank no matter the outcome.
Rating is the ability for contract sides to rate each other. Developer can rate Employer and Employer can rate Developer at closing of the contract. In addition to such rating, successful contract adds to the reputation and failed contract subtracts from it, balancing the human factor. There is also a pattern driven abuse detection algorithm in place to avoid grief or subjective ranking.
Reputation calculates from the ratio of the rank and weighted average rating, and the price of the weight is determined by the time spent on the task, lines and bytes of code produced, and the price of the contract once Developer Sourcing is implemented. This weighting allows to avoid the situation where a few unsuccessful days of work across freelance contracts may ruin the reputation gained in the years of development. However, if the developer manages to pull out a unicorn project in a ridiculously short period of time, it may be recognized accordingly.
To make the codum token a liquid and feasible utility token it has to become the token driving all the operations performed in the codum service network, be it code repository transactions, project management service infrastructure transactions or sourcing developer work. The token will be placed in exchanges for additional liquidity. As the codum platform use grows with time and it’s demand rises, the valuation for codum token and all related cryptocurrency valuation goes up as well. The infrastructure providing the services of the platform needs codum as a fuel to run on, while the demand for such services forces the acquisition of codum in exchanges from other currencies. Project Owner needs codum to run private software development project, code repository and in the future even to hire developers to execute the development itself, which comes as equity investment into the project. Project Owners issue licenses for the access to the private code repositories to gain codum. Then, Project Owners inline with other blockchain infrastructure providers and developers exchange their gained codum for other equity to balance liquidity in the exchanges globally.
GitHub pricing: $9/month per user, starting small teams $25/month includes 5 users. While corporate plans start at $21/user/month requiring additional features and guarantees which would be lived out by the blockchain infrastructure, thus reducing the overall market price.
Bitbucket pricing: free first 5 users, $2/user/month for small teams over 5 users, $5/user/month for large teams requiring additional features and guarantees. This price, however, excludes the project management features of JIRA or Trello, but includes some portion of pipelines and continuous deployment. These are sold as totally separate product with its own pricing, which is a head higher and even more progressive.
Both of the above include the money leaching for long term collaborators and maintainers participating in many projects, as even if they do not contribute any work for a certain amount of time, their presence is charged by the git infrastructure provider. If a developer is participating in 3 large corporate projects on github and takes a month vacation, his presence in the infrastructure costs it’s owners at least $63 for that month alone.
codum pricing for platform services is micro-transaction based and depends on the activity of the network. Even if the price looks high at first, looking into it long term and at a large scale, savings are huge in comparison to the competitors.
Let’s say we plan the pricing to be equivalent to average spending of $2 per user per month with a sane cap of $8 per month for hyperactive users who are either geniuses or do over hours. Only content publishing agencies may find this quite expensive but that is the point. Casual developer might commit up to 2-3 times on average a day while code prodigy would do up to 10 commits on average a day. Pushing the content to the repository accounts in bytes of pushed content, where transaction fee of content is set to be rounded up to 1kB in precision. Due to the nature of how versioned control system works, every turnover in data change is stored in the system, so all the traffic is assumed to be added to the storage as well. We also assume developers work 20 full-time days a month on average. Text (code) content and binary content is accounted for separately.
Assuming the above, codum service pricing should be capped at these FIAT currency prices on launch:
- 0.0025€ per push
- 0.0025€ per 1kB of code/text (non-binary data)
- 0.00025€ per 1kB of binary data
However, in order to avoid the codum platform to fall out of competitive edge in terms of pricing, the pricing will be auto-regulated in relation to other major currencies. For the time being, it is planned to peg it to the mean rate fluctuations of both infrastructure coin (EOS) and Euro FIAT currency.
Costs of Operation
Domain name at .io TLD
Off-chain backend infrastructure cost
Currently it is 12 €/month until codum needs to scale above 20k users or so. Linear scaling is possible for up to 100k users (by adding more CPUs, RAM and storage, up to 60 €/month), then we need to horizontally scale by separating and then parallelizing services and that could suffice for up to 1M users if architected well enough, still fitting within 300 Euro per month. Additional storage will be required time, increasing the monthly cost at about 10% to 20% every year at all scales.
EOS infrastructure cost
CPU and Bandwidth requires EOS stake but does not cost anything in the long run. EOS can be unstaked at any time if capacity is underutilized. The stake can be delegated from other EOS accounts, and that is actually what we are looking at when it comes to production operation.
RAM cost is very dear, and RAM in EOS serves as on-chain permanent data storage. Even though codum is engineered to use as little as possible of such storage, due to the price volatility it is the weakest point of codum economically. At the time of writing, 1kB of EOS RAM, just sufficient to record everything from git push transaction of a single commit of a few files, costs 0.0477 EOS or 0.32 €. The price of RAM needs to fall by 150x for it to be economically feasible even when considering storing just the minimum required portion of the metadata on EOS chain tables. However, by not storing the metadata into EOS tables, but just putting it into transaction parameters, would solve the RAM problem completely reducing it to 0 for this case at the cost of Knife needing to be a full EOS node running off-chain Knife comparison algorithm and reporting finds as transactions back to EOS network. Solution is inspired by decentwitter (source).
EOS Long Term Storage pricing is much lighter, however it will be based on the same principle of buying a share of limited IPFS storage quota offered and managed by Block Producers. However, unlike RAM, it should be priced at cents per gigabyte per month level and be economically feasible.
Sustainability of the codum infrastructure
Owners of staked codum and EOS tokens will get 10% revenue share from the turnover of the token in platform services. These include, but are not limited to: private code repository transactions (push code traffic), repository licensing transactions, and all services introduced in the future.
- The revenue share payout will occur as soon as the revenue reserve account, which would be inaccessible otherwise, reaches 0.2% of the total currently staked codum. On the event of such payout, the revenue reserve amount is deducted from the revenue reserve account, while:
- all the accounts containing active codum stake contracts, get their stake value multiplied by 0.001 added to their account balance, splitting 50% of the revenue share reserve.
- all the accounts containing EOS tokens staked for codum infrastructure, splits 10% of the revenue share reserve.
- the top 60% successful Knife nodes split 30% of the revenue share reserve, depending on their success determined by the reported incidents. In case of no incidents reported during the period, all the reward is returned back to the revenue reserve account.
- 10% of the revenue share reserve is transferred to the codum contribution distribution account, refilling resources required to compensate codum contributors for keeping up codum maintained and developing additional features.
Codum is designed to run and be managed by community. However, until it is technically implemented to function as such, it will be managed by team of delegates assigned by founders and advisors. However, in any point of time due to any kind of violation or disagreement with the majority of the community members of codum, any member of such team can be relieved of duties and replaced by a more suitable person to do the job.
Obstacles for complete decentralization
Classical internet and politics infrastructure, like domain names, branding and all patents on trademarks for codum and codum.io names. Until these can be handed off to the community control in a purely decentralized manner, the domain name and brand name rights are to stay with the founders.
Source code ownership of codum is to stay with the contributors to the codebase, however, anything committed to codum is to be licensed in GPL 3.0 (General Public License 3.0) terms.
Until secure long term private data storage can be implemented in a decentralized manner, such storage is to be managed by founder team and delegated contracted 3rd parties carrying legal responsibility of operating hardware and software storing such highly private data.
Source code control is to stay with codum founders and delegated core developer team until proper decentralized governance over code mechanism is developed and tested. However, such control will stay in the hands of most contributing in terms of value to codum.
codum is issued at 428000000 codum hard cap and will stay at that hard cap forever. The initial network spin-off is sufficient with as little as 1% but the peak network and economic efficiency would start at about 20% of the token supply in perpetual turnover.
Fundraising by Token Sale
Codum token, which are based on EOS and issued for sale and reserved, are equal in value and utility, and do not represent any equity in codum or codum.io organization or community. The sole and only purpose of codum token is the utility in post-launch codum community network ecosystem, to be used for codum platform services (git and project management operations) and software licensing smart contracts.
This token sale section is subject to change without prior notice until EOS Hackathon conclusion, or until the version 3.0 of this Whitepaper is released, where codum will have clearly defined financial plan and will start the token sale process. No change to token distribution scheme is allowed once at least one codum token is sold, and thus such distribution will be hardcoded into the sale and distribution smart contracts. However, total token hard cap, soft cap, private and public sale total token amounts are set in stone and will not be subject to change in case we will need to execute the token sale event.
Round A / Private token sale round
Token cap is 19200000 codum for private sale. Selling 3840000 codum is enough for success of the private sale round, granting the funding sufficient for the project to go on public sale round. If presale would top out, the project would be guaranteed with enough funding for right away allowing the product development to start in parallel with the public sale preparation.
- codum rate offered for the presale period: equivalent of 8 codum for 1 EUR
- Bonus for the first 1.92 million codum: 50% credited when reaching the mark
- Bonus for the second 1.92 million codum: 25% credited when reaching the mark
- Total private presale token allocation with stimulation bonuses: 5280000
Round B / Public token sale round
Capped at 200000000 codum plus the unsold presale tokens and unused presale bonus reserve. 40000000 codum sale is considered public token sale a success granting sufficient funding for the development and launch of the codum platform in full functionality provisioned by this white paper.
- codum rate offered for the public sale period: 4 codum for 1 EUR
- Bonus for the first 20 million codum: 50% credited when reaching the mark
- Bonus for the second 20 million codum: 25% credited when reaching the mark
- Total public sale token allocation with stimulation bonuses: 215000000
The unsold tokens are reserved for the future public fundraising campaigns and for the community bounty for the development of codum. The purpose of such tokens is stimulation of codum post product release economy.
Reserved codum token distribution
Maximum of 192360000 c_ in case of total success in private and public sale, are reserved for distribution to founders, advisors and contributors to the codum development, and a small fraction reserved for company expenses in case the payments can be arranged in codum. In case of just breaking the soft cap on both sales, distributed token allocation can reach 367720000 c_.
The reserved tokens will be initially locked and unlocks at the rate of 10% per 6 months. The first unlock will happen on the estimated public launch date of codum which is set to 9th of September 2019, and the last 10% will be unlocked on 9th of September 2023.
Out of all reserved tokens after the sales has concluded, 100000000 to 275360000 c_ are reserved exclusively for contributors involved into the codum development and will be awarded through smart contracts on the merge event of pull requests through out of the development and the support of the codum platform.
5000000 c_ are used for promotional and social media bounty rewards during the sales.
10000000 c_ are reserved for the company expenses.
The rest 77360000 c_ are distributed to project founders and advisors.
This section is written with the assumption that reader fully understand the inner workings of both git and EOS.io blockchain.
Publishing metadata will be optional for Private/Proprietary code repositories, but will be obligatory for the open source repositories, because not having it would make content of such repositories free for unlicensed grabs. Private code repositories not having public metadata will stay not discoverable as is presently. Portion of Public metadata will be a part of .git directory content in the code repository itself.
Commercially or otherwise sensitive private data, such as personal data (names, addresses, etc.), will be securely stored off-chain to be compliant with GDPR and other possible governmental regulations. Such information is to be centrally managed by founders and their delegated parties maintaining codum off-chain infrastructure until needed, and to be integrated into blockchain infrastructure once it is legally possible. It will be securely and periodically backed up to encrypted redundant undisclosed (but in case of emergency discoverable and accessible) locations.
Structure inside the Blockchain
- Repository Meta (name, project, urls, type, where type is one of Open Source, Proprietary or Private)
- Repository Access Data LayER (RADLER)
- Permission and Access Control, where functionality is inherited from EOS.io with very minimal if any modifications
- License access to git repository maintained by public/private SSH key pairs, where public key is registered to the metadata.
- Branch/Commit tree meta:
- Commit Hash
- Contributor handle
- License Smart Contracts
- Meta contents of Branch/Commit/File tree:
- File path and name hash
- File size, commit change size
- File type (binary/non-binary)
- File line count and line deltas if non binary
- File content type (text/html/python/cpp/hpp/image/pdf/exec/etc.)
- File checksum hash of the current version. Such hash will allow file comparison without having the file itself, integrity checks and so on.
- Current change checksum hash (same as file hash, only applicable to the changes of the current commit)
- Dependencies - Submodule data from git with added Licensing Smart Contract parameters, such as redistribution keys
Structure inside Code Repository
.codum directory, if included, enables public metadata for the repository, with the following content:
- Public readme file path or URL in .links file, symlink or README.* file itself
- Human readable license file path or URL in .links file, symlink or LICENSE.* file itself
- License Smart Contracts
- Any 3rd party integration metadata, for example 3rd party Continuous Integration and Continuous Deployment solutions
- .filehash file, storing meta contents of the current branch/commit/file tree. This file is generated for reference only as a result of the actual commit in git operation, and will never be used as a source for the blockchain data input in the future commits.
- Any file in the repository has an option to contain filename.meta.md file, which may contain important data for the developers considering buying and reusing such code - for example, class descriptions, function headers, use cases, and so on. This would solve partially an issue of potentially buying bad code, as code with proper documentation and .meta descriptions on source files would make it more attractive and show more care and effort been done to support it. Any other document file formats, even filename.meta.docx, are also supported. Privacy disclaimer: all filename.meta.* files of private repository, in case the file itself exists, are considered publicly visible, thus the contents of these filename.meta.* files cannot be secret or otherwise commercially sensitive.
Git source code distribution backend running on blockchain infrastructure
EOSIO software driven public EOS blockchain infrastructure
Long Term Storage implementation in 3 stages
- On initial release, git access to 3rd party git servers via SSH keypair only
- Centralized cloud solution for redundant reliable LTS of codum managed repositories maintained by community under strict, legally binding liability agreements
- EOSIO Storage - an IPFS data storage layer managed by EOS
Current relative Open Source resources to look at
One option of principal implementation for decentralized git operations in torrent network is https://github.com/cjb/GitTorrent - it would require the client to install additional package. Another one is to make a gateway over http, both remotely and locally available, where local would of course require to install the gateway app.
Gitchain (https://github.com/gitchain/gitchain) is currently already unfeasible blockchain implementation on Bitcoin. It failed (2k$ real investment only on Kickstarter in 2014). We can salvage the experience with BitCoin.
- CEO / General Director / Liucijus Urmonas
- CTO / System Architect / Kęstutis Januškevičius
- CFO / Director of Finance / Vacant. Looking for financial expert with CFO experience in large corporations
- CMO / Marketing Director / Vacant. Looking for a Sales Mastermind with public enterprise launch experience
- CCO / Community Manager & PR / Karolina Jasaitytė
On the level with C when it comes to responsibility and decision making
All positions vacant at the moment
Community team members
flat structure, scaling with supply
- Development (40% optimally)
- C++ Developer (EOS dev., git dev.)
- GUI developer / UI/UX master
- Frontend Web dev. (HTML5/CSS3/Angular6+)
- Backend Web dev. (Python/Django/Storage)
- Deployment / Administrators (5% optimally)
- QA / Testing (15% optimally)
- Marketing / Sales (20% optimally)
- Community Support / Social Moderators / Help Desk / PR / Ambassadors (20%)
Hired or outsourced Staff
As long as needed, to be migrated to community team members with time
- Deployment and System Administrators
- Marketing / Sales
- Helpdesk / PR
- Accounting - looking into 100% automagic here
2017-09-01 08:00 UTC, with in-house 3-layer blockchain concept, calculations, done
Logo Designs, design style
2017-10-01 08:00 UTC - 2018-04-24 08:00 UTC, 3 iterations, now final
2018-02-09 08:00 UTC - ongoing
2018-02-26 16:00 UTC, in-review 2.0
2018-04-02 16:00 UTC, in-review 2.1
2018-04-24 16:00 UTC, 2.1.1, community driven update
2018-05-10 11:30 UTC, 2.1.2, roadmap update
2018-06-13 18:00 UTC, 2.1.3, whitepaper bug fixing
2018-06-22 11:00 UTC, 2.1.4, roadmap, private sale postponed by 2 days
2018-06-26 12:00 UTC, 2.2, Knife overhaul, more fixes
2018-07-01 15:00 UTC, 2.2.1, roadmap, private sale postponed by 10 days
2018-07-09 12:00 UTC, 2.2.2, online version live
2018-07-15 20:00 UTC, 2.2.3, roadmap, private presale postponed by a week
2018-07-31 11:00 UTC, 2.2.4, fundraising renamed to rounds A and B, launched
2018-03-19 08:00 UTC v0.1
2018-04-24 08:00 UTC v0.2 EOS Hackathon Edition
2018-07-09 12:00 UTC v0.3 EOS Independance Day Edition
2018-07-31 12:00 UTC - 2018-09-24 12:00 UTC or when all codum round A tokens are sold out
Public Fundraising and Product Development in parallel
2018-10-24 12:00 UTC - 2019-01-24 12:00 UTC or when all codum round B tokens are sold out
Launch of codum.io platform
2019-01-19 - 2019-09-09 09:09 UTC - open developer access, not for production use
2019-09-09 09:09 UTC - public launch of initial codum.io for business, covering these features:
- Secure interface of eos to existing git repositories
- Public metadata of git repository
- Licensing and license templates
- Knife across repositories covered by codum
- Project management and git access UI, including code review
- Licensing and Account management UI
- Sourcing contracts with implemented simple configuration UI
c_ tokens become traded on exchanges
2019-09-09 09:09 UTC, exact exchanges to be announced
Feature Development, Post-Launch maintenance
2019-09-09 12:00 UTC - infinity
Decentralization achieved by codum community
2021-01-01 00:00 UTC - company running codum business suspends it's operations