Make or Bristol Cable

The Bristol Cable has been developed in JavaScript.

There is currently no clear separation between backend and frontend. Furthermore JavaScript is typeless. The database used is MongoDB. The complete application is located in a repository. The test coverage is not complete.

With the help of an ORM and the change from JavaScript to TypeScript two of these points are addressed. But they are not finished yet. Nevertheless, a certain amount of technical debt is being incurred with the system.

Unfortunately the functions of the system are not documented. There is also no documentation of the code and its structure. The knowledge is mainly available through Will in person. Others have to get used to the system accordingly. However, no frameworks in the whole sense have been used, but only libraries as tools. Therefore little knowledge about foreign applications and frameworks is necessary.

The functional range of the system is self-contained. An English payment provider is integrated (GoCardless). Members and subscriptions can be managed. In so-called Call Outs I can send surveys and polls to lists of members. I have the possibility to create deep links with integrated authentication (links with different actions).

There is a referral system allowing users to generate personalised links to invite new members and get a reward from the Bristol Cable Shop.

If our main aim was to take the Bristol Cable system to the market quickly as a proven solution for a community-centered newsroom there would be no major blockers in building based on the code. The weaknesses in the code and lack of documentation could be addressed up front (what is the estimate time this takes?) and the beabee team could put a strong focus on improving the UX and building out the integration of the payment system and the integration of the Crowd newsroom in the first half year before moving on to new features in the second half of the year.

That said, our main goal is to build a long term solution to drive community-centered journalism at big scale in Europe. In that context there is a risk, building based on the existing code base to restrict ourselves from the beginning in a project that should be run agile and based on the input of a number of use cases. In addition there are some risks involved around copyright and development processes being slowed down unexpectedly because of the technical debt we take on and the dependency of Will Franklin who developed the system at the Bristol Cable.

Main risks in working with Bristol Cable Code:

• Investment upfront for documentation and refactoring

• Localisation necessary

• Uncertainties for development process due to technical debt

• Features built in Bristol Cable we would not use in that way (hand over what is not needed or not well developed to new users)

• Be less innovative than we could be

Full evaluation:

• Architectural fit

• It’s mainly about adding functionality. No blockers.

• no modular expansion (or microservices/SCS possible without conversion)

• cannot be used out-of-the-box (Refactoring) > worked on right now

  • MongoDB as database

  • JavaScript is typeless

  • Refactoring is in progress, but not completed.

• required changes to do:

  • OAuth

• Localised for UK

• it is not yet clear whether the existing functionalities will be needed for beabee in the same way

• Quality of the code

• Lack of test coverage

• We would take on some technical debt

• Very special features solving special problems. Not lots of interdependencies or high complexity (/)

• Main weakness is frontend (/)

• User centered design

• Built for exact use case of journalists working community-centered (+)

  • Built for only one specific newsroom (-)

• Product vision

  • Lots of uncertainty. Agile process of building > We could end up with something very different from the Bristol Cable if we start from scratch. (-)

  • Theme, UI/UX needs to be created from scratch (-)

• Speed of development

In terms of functionality, with BC code, we will be ahead of the current product roadmap after year one. (+)

• We can have something for first users to use and test within the first 6 months, focussing on an improved user experience (+)

• Basic requirements of the core CRM features are mostly covered (Member segmentation is missing). We can focus on: Improving the UX, User authentication, etc. (+)

• Some developments will be slower as we have to refactor code (-)

• Extra work: Dividing up code into several repositories as we want the open source code to be usable in modules. > possible to do that as we go. (-)

• When not using the BC code we can still use the acquired knowledge about feature usage, weaknesses and strengths, when building from scratch, and might be quicker at decision making. (/)

• Predictability for timelines

  • For year one and maybe beyond, building off the BC code, it is easier to predict what we can build. This would be a good fit with the Ruhrkonferenz funding which is quite rigid.

• Funding

• Taking the organisation to self-sustainability We have mapped out an ambitious plan for raising funding. It would empower our fundraising quickly because we can show a working system, first users and progress. (+)

• The story might work well as “marketing” in this context. Story of collaboration, solving a big problem together, taking a new approach in European collaboration. (+)

• For the funding needed we will also need to show the novelty of our solution. Better to achieve with a team that builds together from scratch and based on understanding the problems from various use cases. See “product vision”

• Customer acquisition

  • We have our first user with the Bristol Cable early.

• Team

• Will is excited to build beabee with us as backend developer (2 days/week at the start) You don’t easily find developers with that background. Will it be as exciting and encouraging if he has to build things again he has already done?

• Double role of Bristol Cable in the project. Strong interest in having someone take on the software, overly strong stakeholder. Very biased and higher risk of frustration with product than for others.

• Dependencies

• Dependency especially for open source of maintanance by third party.

• Dependencies: With BC code we depend on Will’s knowledge and input.

• Copyright claims and possibly unclarified "direction of travel" possible

• Documentation

• a lot of undocumented knowledge, which is available with Will Franklin as the only person. Upfront work to be done.

Final decision:

Based on the different criteria and an additional review of the single Bristol Cable features, beabee will be building based on the Bristol Cable code. As Will Franklin applied to be Lead developer at beabee (in a freelance capacity), we have the advantage that the maker of the code will develop it further which makes the work on the technical depth something we can deal with easier.

Reasons to move on with the Bristol Cable Code:

• Priority on speed (features over architecture):

• We get to an MVP with fewer resources.

• We can create value for first users early

• Allows us quickly to attract open source developers and to build integrations (Crowdnewsroom/ 100 Eyes)

• We have a baseline to maintain beabee after year one or two with lower resources as pure collaborative Open Source platform (self hosted vs. SaaS)

Risks in uncertainties: 


• We take on technical debt that could slow us down at times

• Weakness of Cable system is the frontend. Frontend will be the focus of the beabee work.

• Cable system already gives us a certain path (trap that we limit ourselves, don’t innovate enough)

Keep in mind for development:

• Don’t overwhelm users: Only show ‘developed’ parts of the software to the user (keep features invisible)

• Ongoing refactoring/reduce technical debt

• Document along the way

• Set up auto testing

• Also: clear separation of roles of Will Franklin as lead developer at beabee and developer and Open Source contributor at Bristol Cable