Church Structure and Software Forks

In order to understand church structure and leadership in a historical context, we can compare them to open-source software, forks and software developers.

Developers (Apostles and elders in the early church) spent lots of time designing, implementing, testing, and evaluating a fantastic system (local church with elders). It was open-source software. They did alpha tests and beta tests and every kind of test they could think of, but they knew that there would be hackers who would come in a change the code and distribute corrupted versions. They also knew that some users would not accept all the functionalities of the original open-source code.

So over time, different forks of the software appeared in different places, each one mostly suitable for the needs of the users in each geographic location and culture. Most of the church leaders were sincere men who loved God and people. However, to preserve their respective forks, they wrote some code that essentially (1) made it impossible to fully follow the original code. It served their purposes at the time, but over time the larger user groups gained dominance, and their forks merged and became standard. The standard was different from the original in many ways, but few people cared, because it suited their perceived needs, and the original developers were no longer around anyway.

Unfortunately, the software developers decided to make the code proprietary, so they could more easily control the users and not allow any new "unauthorized" developers to come up with new forks. That was effective for around 1000 years until some developers (Wycliff, et al.) went back to the original open-source code (the original Greek texts) and made it open source again for amateurs (laymen). They also pointed out some bugs (false doctrines) in the proprietary system.

Although the code for many of the details (like what churches actually did during meetings) was permanently lost, the code they did recover was very helpful to amateurs in getting older forks running again without the need for the prevailing professional software development establishment. Basically, it was a great breakthrough.

There was lots of pushback after one bold developer (Martin Luther) began to publicly attack the proprietary software. The established software developers then made his software illegal and put him on a blacklist, but God protected him. However, there were eventually great conflicts between the two sides (proprietary developers and open-source developers), and it was often bloody.

Today, there is still animosity between the two sides, and the open-source side has also had many forks (denominations). Some developers have made their own forks proprietary. After all, if you want to make money in software development, it can be easier with proprietary software. Software as a service (SAAS) and free software with fees for special services is also available.

Overall, the open-source community is thriving and in all of this, God is somehow still building His Church (Mt. 16:18) and is using people in most of the above forks to do so, i.e., God is using both proprietary and open-source forks, and He has no problem with software developers creating their own forks as long as the original code is not violated.

So, the moral of the story is: always go back to the original open-source code and try to adapt it to your own user situation as best you can. But do not expect all the users to embrace the original source code, especially if they have been using an nth generation fork since childhood. Each software developer must look at both the original source code and his own user base to determine which elements of the original code should and can be implemented.

If you have ever done any software training, you know that the younger users are more likely to fully utilize all the functionalities than the older ones who have been using an existing system. The older people get, the busier they get and the less willing they are to change. They will usually prefer the old system at first, but through patience, some can embrace a new system.

Finally, be ready for the day when most developers will be bought out by the big players (megachurches and the Vatican) and merge their software into one standard global proprietary system (the Beast system - see Revelation 17) in which people must worship the system and reject the original source code. The people who love the original source code will have to go underground to survive, and they will not be able to fly commercial airlines or buy or sell without a digital health pass and DNA-changing vaccines with Luciferase for user identification and authentication. Get ready. It could be rolled out soon in a place near you! Now is the time to start preparing for the shift.