Survey on the current user base - please participate

[christianlupus]

Dear users of PartKeepr,

there is a discussion in #1239 running if the main components of PartKeepr should be reimplemented in another language or from scratch with a more recent version of Symfony. As in this discussion different opinions crashed and no hard facts were present, we need some more information on the current user base.

I am quoting here myself from the google user mailing list:

Such a reimplementation involves quite some effort. It will take man power and time. We want to avoid that after such an undertaking, most of our users are no longer able or willing to use the software. Then, there are two versions (the current one and the reimplemented one) existing and the size of the user base per project has even decreased further.

To get an overview of your options as administrators/users of the PartKeepr project, we prepared a survey. I guess, the survey will take roughly 10 to 15 minutes or a bit more if you write really much in the free-text fields. If you are managing multiple instances, we would kindly ask you to take the survey multiple times, once per instance.

The survey can be reached under the following URL:
https://forms.gle/obFEaiJxFSQBYjHz9

The questions will cover different topics:

• Telemetry data on the instance like number of users, usage etc
• Possible options regarding future system requirements
• User experience and intended use-case

We will let the survey open until June 26th 2022 for participants unless there are valid reasons for an extension of the time range. If you find an important reason to postpone the closing, please contact us.

After the survey has terminated, we will analyze the results and prepare some sort of summary/statistical result sheet. We will provide this in the GitHub issue and also on the other channels we ask for help if possible.

Thank you very much for your support and help

I post this here to avoid the information being lost in the other issue. Also, we will publish the results here in this issue if it has terminsted and is evaluated.

[christianlupus]

The survey has ended yesterday and we promised some statistics to be published. To keep is a bit shorter, I will block the results according to the corresponding sections.

For now these are only the pure data, no interpretation has been on them yet. This might be better of in another discussion/issue.

I will only provide the cumulated results. I had to shorten some of the answers or merged some (e.g. due to typos). Nevertheless, I will provide the original answers literally to the questions. I will, however, not publish the raw answers (as a table) to protect the contributors. If further questions arise and additional statistics would be useful, I can try to provide them.

Please note that the statements are not mine but the results of the survey. So, please do not blame me for anything in it. I am just the messenger and quote the results.

[christianlupus]

Introduction

Are you currently running a Partkeepr instance? (1)

This one is quite clear. We had 70 participants total.

[christianlupus]

Information about the current Partkeepr instance

This section was asking questions related to the current situation.

Wo is the owner if the Partkeepr instance? (2)

The additional answers were:

• I wear LOTS of hats!!!!!!!!!1
• I wear a LOT of hats, so its for me, my family and my business processes
• Student club/ Formula Student team
• University
• we are using PK in a small team at CERN (www.cern.ch) without relation to the official work of the institution

Who is administrating the instance? (3)

How critical is the instance for you? (4)

Additional answers:

• Keeping track of internal stock of components for prototypes
• Mix of above: Have been trying to use a pilot for some productive use. I don't need Enterprise features but do need reliability, security, ability to restore
• PartKeepr is my main home/hobbyist inventory tracking tool, if you can consider this 'production'. That said, it is difficult to impossible to locate my storage bins without it
• Productive, but using it as a hobbyist. But not to have it would give me a major headache.

Have you made some customizations to your Partkeepr instance? If yes, please describe in a few sentences. (5)

• Import of scraped data from sites like LCSC
• I created an additional SQL table for Altium Designer Integration
• I've been looking at trying to customize Partkeepr. There are a few food items listed - - - - would love to use this for pantry/home inventory (pantrykeepr anyone???) might even have another distinct use for partkeepr - - - but I've had it up on a previous server - - - I had to reinstall (other non-related reasons!!) and haven't reinstalled - - - its lots of work to install when one is not a 'sysadmin' (just a serious user!!!) and trying to set up multiple editions is not 'straightforward'.
• No customizations.
• no
• We are running the old version with ZEBRA Printer support https://github.com/Boldie/PartKeeprPrintingService
• No
• I have an error with the search, which was basically broken and I fixed it in some PHP file a while back
• See where this tool would be highly useful in managing a families food stuffs (pantry, fridges, freezers)
• hacking db and code
• I added custom fields for the items (I needed more barcode identifiers)
• Custom scripts for backup (DB dumps).
• Changed default visible columns.
• API integrations with digikey,farnell,mouser and TME
• Filled component database with direct sql query (bash scripts)
• Setup in VM to circumvent legacy issues, Splitted webserver and database for easier backup and setup due legacy issues
• I use a field in the database that was not meant for it as an indicator if I need to print a label
• I've improved the Octopart search to be compatible with the current api
• Just in the ui in the filters to get better extractions
• fixed some pgsql bugs.
• No customizations
• running stock upstream software.

[christianlupus]

System requirements

In this section the focus was on the system the instance was currently running on as well as possible setup for future use. This included both the hardware, the operating system and possible tool stacks on top of that.

How many users are using the instance approximately? (6)

Have you implemented some extensions/plug-ins or something similar based on PartKeepr (7)

What hardware are you currently using to run Partkeepr? (8)

What system are you currently running Partkeepr on? (9)

How have you installed Partkeepr currently? (10)

Which database system are you using currently? (11)

Additional answers:

• MySQL or MariaDB, but can't remember which one
• mysql I think?
• presently on mariadb but would far rather be able to work on postgresql

If the options above do not match your setup well, please give here some details what you did and how you installed the software. (12)

• Proxmox > LXC > Docker
• I had partkeepr installed. For some unusual reasons had to change machines and haven't re-installed yet.
• I's using 0.9 but give up to make 1.x to work, until docker version that works out of the box, so I'm stick no it (and yes the port from 0.9 to 1.x takes me 2 weeks)
• I would use postgres if it were supported
• Not using Linux, the VM is FreeBSD
• Partkeepr, MariaDB, and an NGINX reverse proxy, each in their own containers, shared with other services (Partkeepr is the only thing in its container, but other containers are fronted by the proxy and other containers use the DB). The containers are NOT Docker/etc., they are Linux namespaces w/ distribution installs.
• I used a dockerimage that was thankfully provided by someone cause it was difficult to run outdated php etc.
• Running on Debian 11 with a "janky" manual installation of MariaDB 10.1 as the most recent one provided by Debian is not supported by PartKeepr.
• Installed HTTP+PHP on Linux, running inside a VMware virtual machine
• planning to move it to a Raspberry Pi 4 in the near future.

What hardware could be used for future installations of Partkeepr? (13)

Additional answers:

• Container
• docker

What system would you be running Partkeepr in the future on? (14)

Additional answers:

• FreeBSD
• Possibly FreeBSD or other BSD, but Linux is okay too.

How would you consider to run Partkeepr in the future if you had these options? (15)

Additional answers:

• a Raspberry PI type solution would be interesting
• lost a lot of time and effort trying a version of containers - - - - I'm not an easy sell for trying again - - - that was bloody painful and a lot of time down the tubes!!

Which database systems could be used in the future? (16)

Additional answers:

• I don't care as long as it works
• MSSQL
• Microsoft SQL Server
• SQLite
• Sqlite
• Whatever if bundled in a single docker.
• cockroachdb, sqlite

Do you have any further comments on the technical requirements of any future version of Partkeepr? (17)

• Better modularity (API, plug-in-system, etc) would be great
• any way of changing things so it would be easier to keep updated?
• supporting barcode readers, wifi connection to barcode readers, possibly cell phone apps(via wifi only) is highly useful to me.
• Label printing (directly when making new parts) such as https://github.com/Boldie/PartKeeprPrintingService is essential for us.
• docker would be the best and maybe that the server is scale-able, so multiple partkeepr-servers can run simultaneously for load-balancing if needed
• Dunno if I'm skilled enough to install Partkeepr on Postgresql but would rather much run only 1 database environment instead of having to understand the nuances of 2 different types
• Hey, I don't care wich hardware, nore db, it's not a robot that I'd like to run on a rspi, it's an admin tool, so run it on a normal PC/server like any other tool on the market, BUT focus on easy update, install (only a dozens of super hackers could install the software at once.., nor talking about migration) , add some plugins dev way, themes, more uses cases, admin tools, to manage BOM, distributors, import xls, and this kind of features all we need. I remember that issues to input a 100 pieces invoce from mouser to pk, last 10 years of discussions.. I end doing a hack to permit negative numbers in 'add parts' and modify the script a little to input batch of parts.. so of course when I migrate I loose that.. and also it would help a good full fancy wiki with uses cases, examples, pictures. so, it's a good tool, but the market grows a lot, and there are other tools that has modern features, easy to use and so, and if pk doesn't follow that, it will loose the actual and potential new users... having said that. Thanks your for your amazing job! and hope you found a way to keep working and put pk at top! Pablo
• the biggest constraint in our case is to be able to keep up to date the environment, following the security patches, the actual case where we are fixed with an old version old php starts to be untenable, the IT security team will shutdown our server soon ...
• The only (near-critical) missing feature for me is SSO (Google OAuth).
• I would like the developers to make the code parts most easy to maintain which are dealing with external APIs, like Octopart, Mouser, Reichelt. You get the idea.
• Many projects have turned into cloud based services which takes away ability to have hands-on control of application, integrations, and customizations. Please keep focus on running as an on-premise app
• should be as easy as possible to setup and backup. ie defining a custom path for datasheets and all uploaded documents...
  Also, I had problems running my instance on a small disk because somehow partkeepr creates a lot of subFolders and I was running out of inodes.
  I have to run a cronjob to clean everything (which I don't mind, now that it's set).
• I would strongly prefer that the program and data are separated, not intermingled as they are now, such that the program can be mounted read-only (or at least not readable by the partkeepr user) and the data read-write.
• Keep it on a standard LAMP stack, not everything needs to be overly complicated
• A simpler method for label printing and scanning would be deeply appreciated. I had a look at different partdbs an after careful consideration I found your project the most useful and lean. Only issues for me were the label/printing and the possibility to have sub categories for storages (locker->drawer->box). This issue was one of the biggies of a friend ofme who changed to partdb.
• Labelprinter and barcode scanner support
• Unfortunately web frameworks seem to have the "shelf life of yogurt" as I read somewhere once. It would be best if we could choose frameworks that have been around for a while to minimize the risk of the chosen framework becoming obsolete too soon.
• Preferably self-contained as it need to run parallel to other services and not disturb them

[christianlupus]

Administrative knowledge

In this section the human capability should be evaluated to prevent us from building huge blocks that our userbase is not able to master.

Do you know these tools/systems? [Docker] (18)

Do you know these tools/systems? [Podman] (19)

Do you know these tools/systems? [Virtual Machines] (20)

Do you know these tools/systems? [Kybernetes] (21)

Would you be willing to install and get used to a new tool stack? (22)

Do you know what a reverse proxy is? (23)

[christianlupus]

Community participation

Here are some general questions regarding the activity of our communitry.

Please select the list of things you have done regarding the Partkeepr project. (24)

If you selected that you programmed against the API or the database, what programming language did you use? (25)

• PHP, Python
• PHP
• php, js
• Python (I authored KC2PK)
• sql (basically scripts) and visual interfaces to manipulate the tables
• c# to talk to mysql db
• Ruby
• python,perl,bash
• Java
• bash. (fixing /renaming things. nothing special)
• python 3

Have you participated in other open source projects? (26)

Are you aware that the project is looking for support by the community? (27)

Would you be willing to help with the Partkeepr project in the future? (28)

What was required for you to participate in the community (more)? Is there especially something we can remove that is hindering you? (29)

• )
• Less deprecated framework parts
• I did not have time to participate more
• I would be interested in helping with documentation.
  Find that most programmer types don't write good docs.
  describing things using words is a skill that I've used a lot
  I also have a technical background - - - just not a programming one!
• I am not a developer but a system administrator, could help testing deployment etc
• get launched using it to track my inventory.
• I'm lacking the skills
• I don't know symphony, so I cant really help
• Gain (more and advanced) programming knowledge. I have some basic knowledge, but I do not call myself a programmer.
• Time - - - - for me to effectively assist at some programming would mean to add the necessary skills - - - that would take time not available
• I have no time at present (I have a full time job as a doctor)
• I just don't have the time to dedicate (I can trace a bug when I found it but no much more)
• Some more life in the community. We installed it about 5 years and had some ideas what we needed to implement to really make use of it, but then the development activity of partkeepr just died and we waited.
• The current discussions on Github confuse me. A lot of people suggest a lot of things regarding the new implementation. But no decision was made yet.
  Most confusing for me is that Drachenkaetzchen announced her departure from the project but now also participates by suggesting ways that things should or shouldn‘t be done.
• Use of modern programming language and tooling
• Im a c programmer (controllers), im not fluent on Symfony and all the other webtechnics.
• I am not a PHP (or, really, web) programmer. I am happy to work on things that I understand, but the stack-up of PHP + Symfony + etc. is very deep for the time that I have available. I have worked on web projects with simpler frameworks in the past, but it is not really my Thing.
• Im an Embeeded developer, so i cant help much
• Too many other hardware projects.
• I would need more time - but I doubt you can help with that
• I'm a new PartKeepr user, so I just haven't had the opportunity yet.
• personal time-constraints. not eager of symphony (2). clean, modular code surely helps getting bug fixes from non-professional web-devs (like myself). They're often easy to implement. Whenever complicated dependencies are in place, it hinders self-provided bug-fixes in my experience
• The only barriers are (1) time available to contribute and (2) I am not fluent in web programming
• I am fluent in C and embedded systems. :-/
• TBH I've just heard of the project, but given that's the only open source utility in this area (and seems to be very good and well regarded), I want to offer the little bit of help I can to keep it afloat. So for now, the only thing stopping me is my limited time available, nothing on the project itself.
• more time.
• Documentation

Do you know of the current survey regarding the development capabilities in the comunity? (30)

[christianlupus]

Final thoughts

Here come the final section as open-minded questions.

Do you have any final thoughts or comments on the Partkeepr project? (31)

• For me PartKeepr is already nearly perfect feature-wise. Only maintainability is meh.
• It it a fantastic project
• givent he quality of the program it is a real shame that it hasn't been possible to get partkeepr updated
• I tried to use partkeepr, but due to the missing "one part on multiple storage location" it was not useful for me and my friends. We tried to develop the feature, but was not able to do that due to the limited knowledge of the used technology and the level of documentation. We have found the InvenTree opensource project and started using that, because it fully covers our needs. Unfortunately nowadays I do not have time to participate in the development of PartKeepr. I wish all the best for you and the community.
• I ca mostly offer sw testing rather than coding, and maybe contribute to agroup buy of coding from an expert in symphony. I like the suggestion the golang be used which would be simplifying somehow. I'd like to look at that more. javascript is not my favorite language -- I use C and python more.
• It's an amazing project that is very important for us (>3000 parts in the database)
• if there are people that want to do this, and the rewrite has to be planned and split between developers (ci/cd, issue usage etc.), so it is time efficient and works at the end
  What if we have the newest php framework and than realise, that this is not future-ready because of a lack of features or possibilities - you know what I mean?
  and Thanks for this survey!
• It is a very nice piece of software which needs to gets a second life
  In my personal opinion a complete rewrite is probably the easiest and does not need to cost anything if some people are contributing - updating this old code if not worth the effort compared to rewrite it
• I believe there is much potential in this application, but choices in the past made it difficult for the community to support this project once the initial developer stopped supporting the project. I still believe this application can be of much of a succes for many, especially if the interface can be safely exposed to the internet. Although I do think that the audience is limited and niche.
• the most inportat thing partkeepr have for me is locations - i can crate and use them to locate thing where they are
• My sense is that if the project, as a whole, does not start some movement forward, and quite soon, that between security issues and code breaking due to a lack of updates, that Partkeepr will die. Please start something - - - will it be the best decision - - - only time will tell but activity must commence!
• I have been investigating Inventree https://github.com/inventree/InvenTree which is now quite a mature project. I’ve been a PartKeepr user for several years and been a Patreon supporter. It’s a great project and I really liked the Octopart integration. However it’s not been easy to keep running - I’ve put it on a Pi as it has so specific version requirements that it’s difficult to run alongside anything else. Have tried docker version but I’ve not found it runs well on my older macOS system and seems to hog memory (docker not PK).
  Inventree now has a PartKeepr import and printer support as well as a mobile app.
  I think the Octopart integration was really important - the changes to the API broke this and together with the development stalling has made me look elsewhere.
• there were some key components used that were needing very deep knowledge (dunglas api bundle and symfony framework) and when they did a big step in their versions (going over the average knowledge of the community) the project get stuck. If you relay on the community you must use simple things and even they are simple should be very well explained and documented. Any project dependent on a single smart individual will fail in the long term while very small contributions from a large community will add and move forward the project but for this you must use tools and knowledge that can be handle by average or below average programmers.
• Making a donation is fine
• I think that the state of the Partkeepr documentation as it stands now is a barrier to getting other people involved, and that it is an addressable problem. Updating documentation (particularly for information on how to work around its rapidly aging requirements) or the wiki does not require a deeply invested developer. It is not obvious how community members can get involved, however, with the wiki locked down and no action on github.
• Its great, just keep it as it is, but on a more modern backend :)
• I like the project and use the sw regulary for keeping my hardware inventory. Keep up the good work!
• I'm a professional C++ programmer (embedded systems)
• I had trouble getting the current code base to compile and especially to recognize my new code, because of caching and asset handling. It was not obvious how to do this right. I'm currently implementing multiple projects with Python and Flask. Caching is done (if even needed) by a reverse proxy in front of the application. That makes development easy and predictable.
  PartKeepr is a great project - good luck with the results of this survey!
• Keep it alive please. Improve and modernize the entire stack even if octopart isn't working. This is a Great piece of software.
• a gem. we cannot let this die! :-)
• :D
• Keep up the good work!
• I love PartKeepr and hope this project continues!
• I'd like to see Partkeepr updated for newer versions of php
• I am nothing more than an end-user for hobby use, but even in its stalled state, it is the best open-source tool available without stepping up to a full blown ERP level of overkill.
  I feel there is little to nothing I have to offer to help the project, but still would be very sad to see the project die.

Do you feel some questions in this survey are missing? (32)

• May be regarding the frameworks that were used in PartKeepr implementation.
• maybe - - - but I know enough to know that I don't know enough to know what questions to ask - - - grin!
• Are you willing to fund a (group of) developers to support their investments into this project. Such as patreon.
• I may not be a programmer but I could be quite useful in developing documentation. Have very effective writing skills - - - I also want to see Partkeepr survive!!!
• No
• I didn't understood the questions (2 questions before this) about the survey and programming
• A separate survey inquiring about how users are using Partkeepr and what type of client devices are accessing Partkeepr might be helpful
• not survey particular: I'd like a WIP document with possible solutions going forward (platform) and maybe features. ranked by frequency and/or donation (time/money)
  why? I think concrete plans help attract support.

[christianlupus]

Additional questions

There are for sure some questions that might not be obvious from the results above. Additional questions can be asked here by filtering/merging/.... of the data to get new statements. Here come the results in a rather unordered list.

[christianlupus]

Is the usage of MariaDB/MySQL and PostgreSQL sufficient?

To answer this, the raw data was reformatted such that if a participant declared one of the named database systems as valid that the answer would be Yes, otherwise No.

Answers considered as "No" were literally:

• Whatever if bundled in a single docker.

[christianlupus]

Is PHP a requirement by the user base?

During the discussion, it became obvious that some alternatives to the current PHP-based system were intended by the users. This only affects users that depend on shared webspace as all others might be able to install other software as well. So, here we look only at these 12 participants that declared to think of using a PHP-based webspace for PartKeepr.

The data is reformatted to see if there are other options marked except for the webspace to be used with PartKeepr.

Note: This is a rather small group of 12, so its statistical conclusions are rather soft.

[christianlupus]

How much computational power is available?

To get a grasp on the computational power available, the answers in question 13 are mapped to the categories High, Medium, and Low. The best category is selected for each participant (e.g. Medium and Low would get a Medium in total).

The following answers are considered High:

• Full-fledged computer (home server)
• Dedicated server hardware
• Workstation in background/on demand
• Kubernetes

The following answers are considered Medium:

• Virtual server

The following are considered Low:

• Embedded controller board like a Raspberry Pi
• Hosted Webspace (only PHP aware)

The following answers were free-text and considered unknown:

• Container
• docker