Hello everyone, you may remember I dropped by a while back concerning my cooperative management project.
The idea has evolved to building an open-source Enterprise Resource Planning application specifically for worker’s cooperatives. While most ERP software focuses on driving top-down directives, the goal of this project is to enable the cooperatives to work, make decisions, and resolve disputes more efficiently than basically any other type of company.
Current tech stack: Docker, postgres, nginx, SQLAlchemy, gunicorn, jinja2, Flask, Alembic, and Redis.
Please check out the repository documentation if this sounds like something you may be interested in. The docs include the foundational philosophy document called “Hierarchy by Consent” and there is also a template for an Articles of Incorporation that I intend to include as the first default document template in the software.
I’m still pretty early in the process but most of the tables are set up and I’ve made notes in the the classes explaining the requirements and workflows.
I’ve also got some issues started on Codeberg, mostly related to the front-end, which is where I need the most help at the moment. I will certainly be glad for help elsewhere as well.
It’s an open-source project so there is no immediate financial incentive. Part time contributors are certainly welcome.
There’s a discussion room on Matrix and here is the Repository.
Thanks folks
Sieze the spreadsheets of production
To the office, to fight the corpos!
This looks interesting, though a mighty undertaking. Any reason why not take an existing project and fork it? Or even just an ERPNext module? Would help cover a bunch of potential issues rather than start from scratch. Alternatively, have you thought of what would the MVP be to test it out? That way won’t fall into the do-everything-now trap (been there, done that, don’t recommend). Also, it looks very US-centric, so not gonna ask about GDPR, data security, etc. Instead, re: FE - for prototyping, don’t need design, just functional HTML + forms. Or, can try and poke at some premade or quick-assemble templates. Have you thought about functional (not design) requirements for the user experience, AKA how you imagine the users of this would use it? That is, full day in the office VS checking it once-monthly VS yearly for taxes, etc.
Why not use existing projects? A combination of my specific design requirements not existing anywhere else and my lack of software architecture experience. My background is in systems and organizational theory, and while I have experience in mathematics related programming, this is my first server architecture. So that being said, I’m certainly open to ideas as long as that doesn’t stop it from working right. I am planning on integrating different tools like messaging, and I’ll certainly use something like Continuwuity for that. It’s just that for the core database design it really needs to have a specific integrated schema, at least that’s my opinion. Like I said I’m open to ideas, my goal is to get the project done.
I’m not familiar with ERPNext but it looks interesting. As you pointed out this is US based, so it looks like I would have to take that into account as well.
In terms of sensitive information, the US does have laws about Personal Identifying Information, so the “Party” table has a corresponding “PartyPii” table with information that isn’t subject to audit and can be deleted. Home address, email, phone, etc. It is also stored encrypted, so while I’m sure I don’t have it all figured out yet, these things are on my radar.
In terms of MVP, I will certainly be testing out front-end funtionality as I build it. Start with a login page that accepts a default user and brings you to a dashboard page. Get the accounting going so you can make Journal Entries, etc. Prettymuch going by the “Core Design” section at the start of the README and testing in chunks. But in terms of actually seeing if it meets it’s intended function, unfortunately that comes down to an actual beta version I think. I will need to host it and invite people to participate with “points” instead of money.
Someone over on beehaw suggested Svelte for front-end mock-up so I’ve been playing around with the tutorial. It’s certainly neat. I should be able to get demo pages going without too much trouble, they just won’t look too special.
And yes, I have begun thinking about the day to day. I think non-management members need to have a pretty significant capability with just a mobile version of the pages, since not everyone has an actual computer. But either way I want the information to flow smoothly through the organization.
Thanks for your input!
Thanks for elaborating. To me, it looks like you could definitely use an experienced dev-background person to help organise the project. For example, login is low priority imo - it’s not needed until you’re going into testing. And I mentioned the project being US-focused since I noticed stuff like
eligible_1099in the table design - not a thing outside the US.Also, I’m working on a project for a non-profit, and as part of it I’m doing an audit trail functionality. Ended up thinking real hard over what’s PII you actually need. Turns out, don’t actually need to store phone numbers, for example. Makes life easier. And for data anonymisation - if someone makes a GDPR request, then the email gets replaced with a unique hash +
@redacte.d, and the IP gets salted + hashed, so that the same IP is the same hash in all entries. This is to ensure continuity in the audit trail, plus if someone gets banned for DDoSing, then does a data redaction request, then tries to access again, they can still be blocked since their IP still matches the hash (same logic as to how passwords work). I’m mentioning it since that’s the kind of details that are worth thinking about - however, it’s deep down the rabbit hole of details.Speaking of details, if you’re thinking of mobile, then there’s also the decision of app VS mobile-friendly site. If you want an app, then it’s worth swapping to React right now, since React Native (the framework for creating mobile apps) has a larger community and is more mature. If you’re OK not having a native mobile app, then go with whatever, have fun 😁
I asked about the MVP and day to day useage since that can inform you about what order to implement things. As mentioned above, having a login page is lower priority when starting a project. For example, if based on your knowledge and the feedback from existing cooperative(s) shows that the most heavily used functionality is ex. inventory tracking, then it’s worth building a good inventory tracking system first, and grow from there. Is also why I mentioned forking an existing project - is a huge project, and if you’re going at it solo, it’s gonna be painful.
But, there’s also alternative to forking - copy-paste. Just like artists use references, developers can also reference existing code. So, for example, I don’t know if you’ve seen this sheet (from this post) for additional info how people think co-ops should work, but it’s another piece of info to consider. Though it’s Java, you can still take high level structure or direct code inspiration from Adempiere, they’ve been around long enough to make a bunch of mistakes. There’s also a fork of Adempiere, Metasfresh, which is worth looking at re: how things work. Also Tryton, though that one’s in Python. Mentioning Tryton since it also uses the party approach, and has an architecture that’s worth considering: modularity. Essentially, having the core functionality that ties everything together, and a whole bunch of “modules” that each contain their own logic, SQL, etc.
Which brings me to my last point: it’s great to work on a new project, but learn from my mistakes - think of what it would be like to maintain in 6, 12, 24, 60 months. If you tightly couple everything, all things depend on all other things, the system is going to be fragile, hard to maintain, and less likely to be used. With your background I’m sure you’re already familiar with trying to update something someone else created in a way that doesn’t make sense to you.
So yea, basically, I’m trying to caution you to KISS (keep it simple silly), and not overcommit, lest your project ends up the same way my uncountable exciting startings have ended - in some random dusty git repo, untouched for years, too big or hard or no longer relevant to finish 😅
Yeah I wouldn’t mind an experienced dev taking over the architecture, but I will proceed myself if that person doesn’t come along. If you were worried about it not being applicable outside the US, stuff like the eligible_1099 field could be converted into a “country_config” object or something like that. I’m already planning on supporting all currencies so it would make sense.
In terms of modularity, I’ll have to think about it some more. I’ll spend some time looking into those projects and consulting about it with the LLM today.
Now about that spreadsheet and reddit post. That’s not just something to consider, that’s a person to contact. I would love to see how their ideas have developed in the past 4 years. I’ll have to grab a burner today. Thank you!
In any case, good luck with your project, I hope it turns out wonderful, and you get all the hype and support 😁
