Hey :) Ich habe damals fuer eine Software Firma im Support gearbeitet und kenne die Branche sehr gut. Ich kenne auch die Kongurrenz. Es handelt sich um Software die mit Mitgliederdaten arbeitet und verbunden mit der Aussenwelt ist (Drehkreuze, Lesegeraete etc...) Die Branche ansich ist sehr verschlossen. Wenn man sich fuer eine Software interessiert muss man anfragen, eine Demo gibt es meistens nur ueber Teamviewer von einem Vertriebler, der diese dann vorfuehrt. Es werden alte Konzepte bedient, von Datenbanken wie dbase, Microsoft Access und den SQL Server von Microsoft ist alles vertreten. Die Programme sind aber alle an MS Windows gebunden. Programme sind in kompilierten Sprachen geschrieben, aeltere mit MS Access neure mit C# + .NET. Uterm Strich sind alle historisch gewachsen und ziemlicher Shit. Auch unsere Software war schlecht. Das bestreitet auch niemand, aber um das alles neu zu gestalten ist die Manpower einfach zu klein und zu undynamisch. Aufgrund dem Durcheinander gibt es immer wieder Probleme. Die Branche ist technikfremd und abhängig. So, ja, ich komme zum Punkt. Ich moechte gerne selbst diese Software gestalten. Die Skills sind vorhanden (das mal bitte annehmen). Aber ich wuerde das gerne in Python schreiben (als Webapp und in Kombination mit einem lokalen Programm). Quelltext wuerde ich nicht "verunstalten". Geld verdiene ich mit dem Verkauf von Modulen und Support. In wie weit ist das moeglich damit Geld zu verdienen? Ich habe die Sorge, dass die Software illegal kopiert wird. Kommt das oft vor? Wer hat Erfahrung? Zweitens kann ich nicht jaehrlich fuer die Software durch Lizenschluessel Geld verdienen, wie es oftmals gemacht wird. Oder allgemein: Mich interessiert es, in wie weit man Geld mit Programmen verdienen kann, die aus Interpreter-Sprachen bestehen wie Python und damit nicht nur einen, sondern viele Kunden bedienen will. Ich fände es auch toll, wenn meine Kunden Möglichkeit hätten, den Quelltext zu bearbeiten. Lebe ich in einer zu bunten Welt? Klar es ist von so vielen Faktoren abhängig. Ich kann die Software auch in C++ schreiben und alles mögliche wie Lizenz Abfragen und Kopierschutz einbauen. Aber der Aufwand wäre so viel grösser. Plattformunabhängigkeit wäre auch noch vorhanden aber viel umständlicher. Geht wohl nichts über probieren, oder? (Bin im Ausland ohne Umlaute)
:
Verschoben durch User
Wieviele Kunden gäbe es denn? Und ist die Software denn nicht mit der Hardware verbandelt? Es gibt eine Reihe von Firmen, die Quelltexte anbieten mit der Auflage, diese nicht weiter zu geben und nur gemäß der Lizenz zu nutzen. Die Ganze Branche von (nicht freien) Software-Stacks, sei es ein RTOS oder ein Grafikpaket von Segger. Natürlich wird das dann auch geklaut. Es gibt aber auch viele Ehrlich, die Lizenzrechtlich sauber sein wollen und Deinen Support wünschen.
Egg schrieb: > Aber ich > wuerde das gerne in Python schreiben Erfahrung habe ich damit nicht, aber soweit ich weiss kann man auch Python-Programme kompilieren - die werden dadurch viel schneller und sind nicht lesbar, jedenfalls nicht ohne grösseren Reengeneering-Aufwand. Egg schrieb: > Ich fände es auch toll, wenn meine Kunden Möglichkeit hätten, den > Quelltext zu bearbeiten Dann musst du halt damit leben, was die mit der Software machen. Einschränken kannst du das nur per Vertrag, was heisst du bist auf Ehrlichkeit und guten Willen angwiesen. Wenn die Software für deine Module ist kann es auch passieren, dass jemand nicht nur die Software klaut sondern auch die Module nachbaut. Die Frage ist nur, sind die Stückzahlen so gross dass es für Chinesen interessant ist. Trotzdem viel Erfolg Georg
Ich habe das nicht alles verstanden, aber es wird schwer in so etwas hereinzukommen. Unabhängig steht von dem Kaufpreis immer das Risiko eines Platformwechsels im Raum. Da geht auch schnell ein Kunde verloren, d.h. je nach Industrie locker gut und gerne mit 1 Million Euro zu bewerten. Jetzt musst Du mit Deiner Software einen finanziellen Vorteil (messbar) generieren, der höher als die Kosten und das Risiko ist. Bei nich opensource kommt noch das Risiko des Ausfalls des Herstellers (Du) hinzu, und der wiegt alle Vorteile auf.
Egg schrieb: > In wie weit ist das moeglich damit Geld zu verdienen? Sagst du doch selber: > Geld verdiene ich mit dem Verkauf von Modulen und Support. Egg schrieb: > Mich interessiert es, in wie weit man Geld mit > Programmen verdienen kann, die aus Interpreter-Sprachen bestehen wie > Python und damit nicht nur einen, sondern viele Kunden bedienen will. Nun, auch wir müssen den Kunden unseren Quelltext geben, damit die Sicherheit besteht, weiterarbeiten zu können, auch wenn wir uns vom Markt zurückziehen. Es gab einen einzigen Kunden der sich selbst an Weiterentwicklung und Verbesserungen kümmern wollte (und gescheitert ist), alle anderen haben uns SELBSTVERSTÄNDLICH bezahlt, denn das ist die Leistung eines Softwareanbieters im Gegensatz zu open source. Im grossen und ganzen ist Software, die auf Paketen basiert, wie Python aber auch Java, eher lästig: Mit jeder neuen Version muss man nacharbeiten damit es immer noch funktioniert. Daher ist Software die auf low level APIs aufsetzt, auf Dauer kostensparender.
Egg schrieb: > Uterm Strich sind alle historisch gewachsen und ziemlicher Shit. Auch > unsere Software war schlecht. Das bestreitet auch niemand, aber um das > alles neu zu gestalten ist die Manpower einfach zu klein und zu > undynamisch. > > Aufgrund dem Durcheinander gibt es immer wieder Probleme. Die Branche > ist technikfremd und abhängig. > > So, ja, ich komme zum Punkt. Ich moechte gerne selbst diese Software > gestalten. Die Skills sind vorhanden (das mal bitte annehmen). Aber ich > wuerde das gerne in Python schreiben (als Webapp und in Kombination mit > einem lokalen Programm). Quelltext wuerde ich nicht "verunstalten". Geld > verdiene ich mit dem Verkauf von Modulen und Support. Wie wäre es, die SW zu entwickeln u. "deiner" Firma zu "verkaufen"? Wobei ich mich natürlich frage, wie es zusammenpasst, dass unzureichende Manpower einer Firma moniert wird u. eine Einzelperson das völlig kompensieren könnte.
Meine KI meinte, sie hätte einen Troll erkannt. Als Begründung gab sie an, dass die Punkte über den a's, u's und o's keine Fliegenscheiße wäre. ;) Egg schrieb: > (Bin im Ausland ohne Umlaute)
G. L. schrieb: > dass unzureichende > Manpower einer Firma moniert wird u. eine Einzelperson das völlig > kompensieren könnte. Man erinnere sich an Stallmans GNU-Community, dem die Manpower für einen Kernel fehlte ...
> Wieviele Kunden gäbe es denn? c.a. 10.000 und mehr. Die sind momentan auf ungefähr 4-6 verschiedene Software Firmen verteilt. Einige benutzen bisher auch gar keine Software, da die Grossen zu komplex sind, viel Geld verlangen und einfach zu umfangreich sind. > kann man auch Python-Programme kompilieren - die werden dadurch viel schneller und sind nicht lesbar Das kann man zu einfach rückgängig machen. Die 'kompilierte' Version ist nicht wirklich sicher. Einen Lizenz Schlüssel kann man da nicht abfragen. Wäre zu einfach zu umgehen. Python kompiliert jedes Programm vor der Ausführung sowieso. Für Chinesen ist da kein Markt. Zu wenig Kunden. Die Branche braucht auch den Support. Outsourcing wäre schwer. Das lohnt sich nicht. Die Module baue ich ja selbst nach. Das Rad neu erfinden mache ich selbst nicht. > Unabhängig steht von dem Kaufpreis immer das Risiko eines Platformwechsels im Raum. Das ist tatsächlich mein grösster Feind. > Daher ist Software die auf low level APIs aufsetzt, auf Dauer kostensparender. Klingt fast zu schön um wahr zu sein. Es ist halt doch Anwender Software. Sowas low level zu programmieren ist fast zu aufwendig. Ich programmiere gern low level. Aber hier geht mir auch teilweise die Plattformunabhängigkeit verloren. Man bedenke auch alle gängigen Linux Distros zu bedienen... Python3 scheint mir recht stabil, inzwischen... > Wie wäre es, die SW zu entwickeln u. "deiner" Firma zu "verkaufen"? Nicht möglich. Die bleiben bei Microsoft und dem SQL Server. Man hat sich auch vor kurzem für C# entschieden. Datenbank wird selbst nicht aufgeräumt. Abwärtskompatibilität kreiert Bloat und alte Muster... Ich möchte das nicht. Teile der Software sind in verschiedenen Sprachen geschrieben. Delphi ist auch dabei. Zudem arbeitet man neben den Datenbanken mit der normalen Ordnerfreigabe von Windows. Keiner hat Bock das zu ändern... > Wobei ich mich natürlich frage, wie es zusammenpasst, dass unzureichende Manpower einer Firma moniert wird u. eine Einzelperson das völlig kompensieren könnte. Ich fange klein an. Meine Software kann am Anfang nicht mit dem Grossen konkurrieren. Es gibt verschiedene Hardware Hersteller für Lesegeraete. Ich fange als erstes nur mit einem an. Die kleine Kunden aber völlig ausreichend. Alles andere kommt später. Hätte noch einen weiteren Programmierer zu Hand. Vielen Dank für das Interesse und die Antworten! Das hilft mir sehr.
Das Ganze hört sich für mich nach Zutrittskontrollsystemen an, wie z.B. SKIDATA
Was waere der Vorteil fuer den Kunden Deine Software zu verwenden?
> In wie weit ist das moeglich damit Geld zu verdienen? Ich habe die
Sorge, dass die Software illegal kopiert wird.
Was fuer eine Lizenz schwebt dir dann vor ? Pro Stueck ? pro Kunde ? Pro
Arbeitsplatz ? Wie willst du das kontrollieren ? Ohne Kontrolle kommt
nichts.
Open sorce ist gut, aber das Geld kommt vielleicht etwas schleppend. Wie
sollen die Kunden motiviert werden etwas zu bezahlen ?
Wie oft und wieviel hast du schon als einen Beitrag an Wikipedia,
Mozilla, oder dergleichen bezahlt ?
> Das Ganze hört sich für mich nach Zutrittskontrollsystemen an, wie z.B. SKIDATA Ja, das trifft es sehr gut. > Was waere der Vorteil fuer den Kunden Deine Software zu verwenden? Einfache Installation, Plattformunabhängigkeit, offener Quelltext, keine Begrenzung der Arbeitsplätze, mehrsprachig, (Web App, keine lokale Installation nötig), (Preis) > Was fuer eine Lizenz schwebt dir dann vor ? Pro Stueck ? pro Kunde ? Pro Arbeitsplatz ? pro Kunde pro Einrichtung. Kontrolle gibt es nicht. Die Software wird einmal gekauft. Dazu Installations und Supportkosten. Updates free, wenn für Support bezahlt wird. Software/Quelltext darf nicht weitergegeben werden. Änderung des Quelltextes möglich. Weitergabe möglich, wenn es als Modul programmiert wurde. > Open sorce ist gut, aber das Geld kommt vielleicht etwas schleppend. Wie sollen die Kunden motiviert werden etwas zu bezahlen ? Wie oft und wieviel hast du schon als einen Beitrag an Wikipedia, Mozilla, oder dergleichen bezahlt ? Kunde muss am Anfang die Software erwerben. Schulung. Installation. Dann Support, falls gewünscht. Ist aber wichtig, da Hardware auch eine grosse Rolle spielt. Habe für Wikipedia schon mehrmals gespendet. Hatte nie Probleme für Software Geld zu bezahlen.
Probiere es doch einfach mal aus! Notfalls klaut es einer und Du suchst Dir eine neue Idee! Aber in technikfernen Branchen wird das eher nicht passieren. Evtl. kannst Du die Software ja so absichern, dass sie nach Hause telefoniert. Dann könntest Du illegale Nutzer abmahnen. Die werden meist zu dumm sein, um den entsprechenden Code zu ändern.
Offener Quellcode = Sklave des Kunden. Zudem man als kleiner Krauter auch nicht immer innovativ arbeiten kann, da muss man mal Steuern erledigen, andere bürokratische Dinge usw. Wenn man dann mal Familie hat benötigt diese auch Zeit. Es gibt meiner Ansicht nach nur sehr wenige die mit Opensource als Einzelunternehmen Erfolg haben, langfristig eher überhaupt keine da sie von der Technik und den Jungen überholt werden.
Egg schrieb: > Die > Programme sind aber alle an MS Windows gebunden. Programme sind in > kompilierten Sprachen geschrieben, aeltere mit MS Access neure mit C# + > .NET. Und? Geht es dir nur um einen Sprachenstreit? Ja, das Zeug ist teilweise "legacy", aber was soll's? Praktisch jede Firma verwendet Windows und hat kein Problem damit Windows-Software auszuführen. > Aber ich > wuerde das gerne in Python schreiben Also es geht nur darum alles in eine Modesprache neu zu machen die du magst? Das ist eigentlich nur unprofessionell. Welchen Vorteil bringt Python für das Endprodukt das der Kunde sieht? Warum glaubst du, dass Anwender nur darauf gewartet haben, dass alles nochmal in Python gemacht wird? > (als Webapp und in Kombination mit > einem lokalen Programm). Himmel, wir haben nicht mehr 1999. Das ist doch sowas von out. Du beschwerst dich über Legacy, aber willst nicht in die Cloud mit eine XaaS-Modell? Bah, wie altmodisch. Und dann Python, und nicht node.js? Ohne Big Data und Machine Learning im Backend? Merkst du was? Dieser ganze Sprachenstreit und was alt ist, ist sowas von witzlos. Morgen kommt immer jemand mit was Neuem. > In wie weit ist das moeglich damit Geld zu verdienen? Du sagst du kennst die Branche, was fragst du uns? Wie wird in der Branche normalerweise Geld verdient? Was fehlt an Produkten - nicht in Form von Programmiersprachen, sonder Funktion die der eigentliche Anwender sieht? Warum benötigt die Branche unbedingt Webapps, statt Windows-Programme? Noch eins: > Es handelt sich um > Software die mit Mitgliederdaten arbeitet und verbunden mit der > Aussenwelt ist (Drehkreuze, Lesegeraete etc...) Wenn Kunden Geräte wie Drehkreuze einsetzen, die im Extremfall Personen schwer verletzen oder töten können, dann haben sie gerne jemanden, der ihnen eine "Garantie" gibt, einen Versicherungsschutz und den sie im Notfall verklagen können. Glaubst du, viele Anwender werden von der Herstellersoftware auf deine wechseln wenn sie damit die Hersteller-Garantie und vielleicht ihren Versicherungsschutz verlieren? > Oder allgemein: Mich interessiert es, in wie weit man Geld mit > Programmen verdienen kann, die aus Interpreter-Sprachen bestehen wie > Python und damit nicht nur einen, sondern viele Kunden bedienen will. Du hängst dich viel zu sehr an der Sprache auf. Wenn das sowieso eine Webapp sein soll, warum bleibt der Python-Code nicht auf dem Server, sondern gelangt in die Hand des Kunden? Ach, weil der Kunde für deine Anwendung jetzt noch einen Server betreiben muss? > Ich fände es auch toll, wenn meine Kunden Möglichkeit hätten, den > Quelltext zu bearbeiten. Lebe ich in einer zu bunten Welt? "Sehr geehrter Schadensregulierer der Versicherung WirZah-LenNie, die Drehkreuzsoftware wurde von unserem IT-Hausmeister in seiner Freizeit entsprechend unseren Anforderungen angepasst. Wir verstehen nicht, warum sie sich im Fall des Unfalls von Herrn Klemmdie Handein weigern zu zahlen." > Plattformunabhängigkeit Wie viele der Kunden brauchen Plattformunabhängigkeit? Du sagst du kennst die Branche, also wie oft fragen Kunden danach? > Geht wohl nichts über probieren, oder? Kannst'e machen.
Beitrag #5366739 wurde von einem Moderator gelöscht.
Ein moegliches Szenario : Prospektiver Kunde... Wir machen einmal eine Testlauf des Systems, haetten aber noch gerne eine Aenderung oder zwei ... du machst diese kostenpflichtige Aenderung. nach einem halben Jahr rufst du an ... nein, das System war nicht brauchbar, bla, bla, ... wir haben das Projekt gestoppt. es verkauft sich aber extrem gut. Aber weshalb abdruecken wenn's nicht erzwungen wird?
> Kunde muss am Anfang die Software erwerben. Schulung. Installation. Dann > Support, falls gewünscht. Ist aber wichtig, da Hardware auch eine grosse > Rolle spielt. Welchen Vorteil hat denn der Kunde gegenüber der Uraltsoftware. Du sagst ja selbst die Branche ist technikfeindlich - geht die Zutrittskontrolle schneller? Schulungsaufwand ?! Was meinst Du denn warum Linux bzw. Openoffice sich nicht durchgesetzt hat, obwohl es kostenlos ist? Die Firmen haben keinen Bock auf lange Umschulungen und als Ein-Mann-Betrieb kannst Du es gleich vergessen, Dein Konzept stimmt nicht.
:
Bearbeitet durch User
georg schrieb: > Egg schrieb: >> Aber ich wuerde das gerne in Python schreiben > > Erfahrung habe ich damit nicht, aber soweit ich weiss kann man auch > Python-Programme kompilieren - die werden dadurch viel schneller und > sind nicht lesbar, jedenfalls nicht ohne grösseren > Reengeneering-Aufwand. Es gibt dabei mehrere Ansätze. Einerseits kann Python natürlich Bytecode erzeugen. Das ist das normale Verhalten beim Laden von .py-Modulen, die dabei in .pyc-Dateien mit (ggf. optimiertem) Bytecode übersetzt werden. Dann gibt es "Compiler", die den Python-Code nur packen, dafür sind py2exe, py2app oder cx_Freeze wohl die bekanntesten Beispiele. Da wird der Python-Interpreter mit dem Code des Projekts zusammen in ein Executable gepackt, so daß auf dem Zielsystem keine Python-Installation mehr nötig ist. Keine Ahnung, ob der Code vorher in Bytecode übersetzt wird und ob man ihn aus der erzeugten Executable extrahieren kann. Andererseits gibt es nuitka und Numba, die Python in C- oder C++-Code übersetzen und dann meist auch gleich Maschinencode daraus erzeugen. Und dann gibt es im Jython-Projekt noch den Compiler jythonc, der Python- in Java-Code übersetzt, der dann mit den Java-Compiler natürlich in ganz normalen Java-Bytecode kompiliert werden kann. Die letzten beiden Optionen können je nachdem einen signifikanten Speedup leisten, das Übersetzen in Bytecode oder das Packen in ein Executable hingegen bringen da ziemlich wenig. > Dann musst du halt damit leben, was die mit der Software machen. > Einschränken kannst du das nur per Vertrag, was heisst du bist auf > Ehrlichkeit und guten Willen angwiesen. Wenn die Software für deine > Module ist kann es auch passieren, dass jemand nicht nur die Software > klaut sondern auch die Module nachbaut. Die Frage ist nur, sind die > Stückzahlen so gross dass es für Chinesen interessant ist. Wenn die Stückzahlen groß genug sind, schreiben die Chinesen sich ihre eigene Software. ;-)
Michael B. schrieb: > Im grossen und ganzen ist Software, die auf Paketen basiert, wie Python > aber auch Java, eher lästig: Mit jeder neuen Version muss man > nacharbeiten damit es immer noch funktioniert. Daher ist Software die > auf low level APIs aufsetzt, auf Dauer kostensparender. Das ist Unsinn.
G. L. schrieb: > Wobei ich mich natürlich frage, wie es zusammenpasst, dass unzureichende > Manpower einer Firma moniert wird u. eine Einzelperson das völlig > kompensieren könnte. Liegt an der Sprache: in einer Skriptsprache kann der Entwickler wesentlich schneller arbeiten als in kompilierten Sprachen, dafür ist interpretierter Code üblicherweise nicht so performant wie kompilierter. Das ist der ganze Trick an Skriptsprachen: man handelt Entwicklungs- gegen Laufzeit. Gerade deswegen sind Skriptsprachen so stark in Domänen mit häufigen Änderungen am Code, zum Beispiel in der Webentwicklung und der Datenanalyse.
Bei Zutrittskontrollsystemen usw. geht es doch nicht um die neueste Modeprogrammiersprache, sondern um die Zuverlässigkeit. Bekannte hatten damals die Software für die Cebit entwickelt und mussten eine Versicherung finden, die bereit war, die Kosten eines möglichen Ausfalls zu decken. Ein erheblicher Teil der Entwicklung bestand dann plötzlich nicht mehr um der Umsetzung der Technik, sondern in dem von der Versicherung geforderten Nachweisen und Zertifizierungen, usw.. Wenn man nun also dem Kunden sogar explizit ermöglicht, in der Software herumzupfuschen, schafft man Haftungsrisiken, an die man vorher niemals dachte. Plötzlich steht man mit einem Fuß im Knast, weil die vom Hilfsklempner des Kunden durchgeführten "Anpassungen" dazu führen, dass die Software abstürzt und eine Entriegelung der Drehkreuze usw. für die Rettungskräfte nicht mehr funktioniert.
Du hast keinen Business Case. Normalerweise fängt man nicht damit an, sich zu überlegen wie man etwas machen will, sondern warum und was dein Produkt dann besser kann. Gibt es etwas in den aktuellen Produkten was die Kunden nicht damit tun können und du lösen kannst? Die Programmiersprache und die verwendeten Tools sind in (fast) jedem Projekt zweitrangig. Ob ich nun mein Backend in Java oder in C# implementiere, ist fast schon eine akademische Frage... Du sprichst übrigens von Problemen. Kannst du diese Probleme lösen? Und "sieht" der Kunde diese Probleme in Form von höheren Kosten (z.B. wegen Downzeiten oder benötigten Instandhaltungen) oder schlechterer Funktionalität? Oder treten die Probleme nur bei euch in der Entwicklung auf, weil man eben umständlicher Programmieren muss und haben diese Probleme dann im Endprodukt eigentlich keine Auswirkungen. Falls "nur" letzteres wird es schwer, einen Kunden zu überzeugen, dir für eine Neuentwicklung Geld zu geben...
Andreas S. schrieb: > Bei Zutrittskontrollsystemen usw. geht es doch nicht um die neueste > Modeprogrammiersprache, Eine 27 (in Worten: siebenundzwanzig) Jahre alte Programmiersprache als "neueste Modeprogrammiersprache" zu bezeichnen, ist zumindest mutig. ;-)
Was ein einzelner Entwickler entwickeln kann, das lohnt sich nicht zu reverse-engineeren. Der Aufwand ist quasi genau so groß wie es neu zu entwickeln - inklusive eingener neuer / besserer Ideen. Andersherum ist es das Knowhow über den bestehenden Code, was den Entwickler für Erweiterungen, Bugfixes, etc. das, was diesen Spezialisten wertvoll macht. So gesehen halte ich die Frage quelloffen oder nicht für einen Sturm im Wasserglas.
Thomas M. schrieb: > ein einzelner Entwickler 1.Hatte ich leider schon, daß ein einzelner, guter Entwickler durch Flugzeugabsturz zu Tode kam. Seitdem mache ich um Einmann-Entwicklungen möglichst einen Bogen. 2.Solch ein Geschäft kann man nur nebenbei anfangen um zu sehen wie es läuft. Andererseits würde ich nie voll einsteigen als Einzelkämpfer. Da ist 7x24h nicht mehr an Urlaub und Freizeit zu denken, wenn die Kunden rufen.
Also in meinem Fall sind innerhalb der letzten 10 Jahre 2 mittelständische Unternehmen voll ausgestattet mit Hardware und Software-Entwicklern in Konkurs gegangen. Übrig geblieben ist die 1 Mann Klitsche. Hab dadurch auch Konzernaufträge bekommen. Die meiste Zeit geht eigentlich für's Lernen drauf und nicht für die effektive Arbeit.
FamilyGuy schrieb: > Übrig geblieben ist die 1 Mann Klitsche. Ausnahmen bestätigen die Regel. Was wird, wenn der EINE Mann in Rente ist? Stehen dann alle Drehkreuze des o.g. Zurittssystems still, weil keiner ablaufende Zertifikate erneuert? :-)
Beitrag #5370332 wurde von einem Moderator gelöscht.
oszi40 schrieb: > Was wird, wenn der EINE Mann in Rente ist? Stehen dann alle Drehkreuze > des o.g. Zurittssystems still, Ẃenn die Quellen mit gekauft worden sind kann das theoretisch ein andrer weiter pflegen. Irgendwelche Zertifikatsgeschichten ebenso.
Bernd K. schrieb: > Ẃenn die Quellen mit gekauft worden sind kann das theoretisch ein andrer > weiter pflegen. Irgendwelche Zertifikatsgeschichten ebenso. Bei 3 Zeilen Code kein Problem, bei xx tausend mühevoller, je nach gepflegter Dokumentration?
> Das Ganze hört sich für mich nach Zutrittskontrollsystemen an, wie z.B. SKIDATA Du hast es erfasst. Es gibt hier und da noch weitere Spezialisierungen aber grundsaetzlich geht es um Mitgliederverwaltung, Abrechnungen, Statistiken und Zutrittsloesungen. > Was waere der Vorteil fuer den Kunden Deine Software zu verwenden? . Einfachere Bedienung und Installation . Plattformunabhaengige Installation . Software wird einmal gekauft und laeuft nie ab . Software laeuft komplett im Browser, keine lokale Installation der Clients noetig --> Unendlich viele Arbeitsplaetze moeglich --> einfacherer Update-Mechanismus . Offener Quelltext Es gibt groessere Kunden die einen ITler beschaeftigen. Diese sind hier und da zurecht sehr boese geworden als diese gesehen haben, dass alte Runtimes fuer Access verwendet wurden, mit Bugs und ausgelaufenem Support... Zweitens muss man lokal viel tun, damit die Sache funktioniert. Ist ein Mischmasch aus lokaler Installation, Datenbankanbindung und freigegebenen Windows Ordnern. Ein einzelner Client kann dem ganzen System viel Schaden zufuegen. Keine wirklichen Sicherheitsmechanismen vorhanden. Viele Itler unterstuetzen Windows als lokale Maschin, fragen aber oft obs fuer den Server eine Linux Maschine tut. Weil dort einfach weniger rumgepfuscht wird. Es gibt bisher keine Linux Loesung auf dem Markt. Das sehe ich als Luecke und als Hoffnung. > Offener Quellcode = Sklave des Kunden Mhmm... das sehe ich nicht so. Ich wuesste nicht wieso das bei einer Binary nicht sein sollte. Man kann sich immer zum Sklaven oder von einem grossen Kunden abhaengig machen. > Und? Geht es dir nur um einen Sprachenstreit? Ja, das Zeug ist teilweise "legacy", aber was soll's? Praktisch jede Firma verwendet Windows und hat kein Problem damit Windows-Software auszuführen. Ich halte Python fuer eine gute Wahl. Ich komme aus dem low level Umfeld und bin froh, dass ich dieses Know How habe. Ich bin keiner dieser Fanboys die aus dieser Python Sprache eine regelrechte Religion machen. Ich will plattformabhaengig entwickeln um selbst Kosten in der Produktion zu sparen. > Wenn Kunden Geräte wie Drehkreuze einsetzen, die im Extremfall Personen schwer verletzen oder töten können, dann haben sie gerne jemanden, der ihnen eine "Garantie" gibt, einen Versicherungsschutz... In meinem Fall sind das keine automatischen Drehkreuze. Es sind kleine Zugangsloesungen, die ueber einen potentialfreien Kontakt angesteuert werden. Faellt der Strom aus, sind diese dauerhaft offen. Neben der Softwareloesung gibt es noch eine mechanische. Ich bin uebrigens auch gelernter Elektroniker. > sondern gelangt in die Hand des Kunden? Ach, weil der Kunde für deine Anwendung jetzt noch einen Server betreiben muss? Du musst immer einen Server betreiben. Auser bei einer Einzelplatzinstallation. Da ist der Rechner Client und Server in einem. Er braucht keinen unabhaengigen Server, wenn die Software nicht Tag und Nacht laufen muss. Bei einem kleinen Buero mit 2 Arbeitsplaetzen reicht es, wenn einer davon auch der Server ist. > Wie viele der Kunden brauchen Plattformunabhängigkeit? Du sagst du kennst die Branche, also wie oft fragen Kunden danach? Wenn es um den Server geht fragen vor allem IT Dienstleister, ob sie das nicht mit einer Linux Maschine machen koennen. > Was meinst Du denn warum Linux bzw. Openoffice sich nicht durchgesetzt hat, obwohl es kostenlos ist? Weil es hierfuer fuer diese Art von Software keinen Markt gibt. Langsam gibt es aber einen. Weil die Kunden langsam die Gedult mit Microsoft verlieren (Lizenzen..., du zahlst inzwischen fuer jeden Benutzer in der Cloud. Bei einem Unternehmen mit wechselnden Personal einfach richtig umstaendlich). Zweitens wird die Hardwareansteuerung immer einfacher. Lesegeraete, Bondrucker, Drucker und andere Hardware kann komplett ueber Netzwerkschnittstellen angesteuert werden. > Einerseits kann Python natürlich Bytecode erzeugen. Das ist das normale Verhalten beim Laden von .py-Modulen, die dabei in .pyc-Dateien mit (ggf. optimiertem) Bytecode übersetzt werden. Das ist kein Bytecode. Du kannst den Quelltext immer noch lesen. Es gibt auch von Python selbst Programme die das rueckgaengig machen. Ich will meinen Quelltext nicht verunstalten. Ich moechte das erfahrene Leute erkennen, dass ich ordentlichen Code schreibe. Die Qualitaet des Quelltextes spiegelt sich im Programm. Die Java Uebersetzungen scheitern sicher wenn es um eingebundene Module geht. > Liegt an der Sprache: in einer Skriptsprache kann der Entwickler wesentlich schneller arbeiten als in kompilierten Sprachen... Sehe ich auch so. Ich brauche einige Module fuer die Software: Verschluesselung, Sockets, Grafik-Tools, Webserver Funktionen etc... Ich muesste bei C++ die Libraries immer wieder checken. Bei Python weiss ich, dass alles auf dem aktuellen Stand ist, wenn ich mit der derzeitigen Python Version Schritt halte. > Du hast keinen Business Case Das kann zu einem Problem werden. Ich komme von der technischen Seite. > So gesehen halte ich die Frage quelloffen oder nicht für einen Sturm im Wasserglas. Ich denke genauso. Muss ich ja, sonst wuerde ich das nicht probieren wollen. > Hatte ich leider schon, daß ein einzelner, guter Entwickler durch Flugzeugabsturz zu Tode kam. Seitdem mache ich um Einmann-Entwicklungen möglichst einen Bogen. Ich will nicht zwingend alleine bleiben. Wenn die Software funktioniert und ich mehr Leute brauche, dann stelle ich auch gerne Personen ein. Aber ich weiss auch, dass es bis dahin harte Arbeit sein kann. Vielleicht ist es auch nie moeglich. Die Software ist quelloffen, immerhin etwas falls ich von heute auf morgen nicht mehr da sein sollte. > Solch ein Geschäft kann man nur nebenbei anfangen um zu sehen wie es läuft... So wird es auch vermutlich geschehen. Vielen, vielen Dank fuer die vielen Antworten. Auch gut, dass hier und da mal wirklich aus dem "Naehkaestchen" berichtet wurde. Ich probiere das auf he
Edit: Bitte obigen Beitrag loeschen, aufgrund falscher Zeilenbruechen. > Das Ganze hört sich für mich nach Zutrittskontrollsystemen an, wie z.B. SKIDATA Du hast es erfasst. Es gibt hier und da noch weitere Spezialisierungen aber grundsaetzlich geht es um Mitgliederverwaltung, Abrechnungen, Statistiken und Zutrittsloesungen. > Was waere der Vorteil fuer den Kunden Deine Software zu verwenden? . Einfachere Bedienung und Installation . Plattformunabhaengige Installation . Software wird einmal gekauft und laeuft nie ab . Software laeuft komplett im Browser, keine lokale Installation der Clients noetig --> Unendlich viele Arbeitsplaetze moeglich --> einfacherer Update-Mechanismus . Offener Quelltext Es gibt groessere Kunden die einen ITler beschaeftigen. Diese sind hier und da zurecht sehr boese geworden als diese gesehen haben, dass alte Runtimes fuer Access verwendet wurden, mit Bugs und ausgelaufenem Support... Zweitens muss man lokal viel tun, damit die Sache funktioniert. Ist ein Mischmasch aus lokaler Installation, Datenbankanbindung und freigegebenen Windows Ordnern. Ein einzelner Client kann dem ganzen System viel Schaden zufuegen. Keine wirklichen Sicherheitsmechanismen vorhanden. Viele Itler unterstuetzen Windows als lokale Maschin, fragen aber oft obs fuer den Server eine Linux Maschine tut. Weil dort einfach weniger rumgepfuscht wird. Es gibt bisher keine Linux Loesung auf dem Markt. Das sehe ich als Luecke und als Hoffnung. > Offener Quellcode = Sklave des Kunden Mhmm... das sehe ich nicht so. Ich wuesste nicht wieso das bei einer Binary nicht sein sollte. Man kann sich immer zum Sklaven oder von einem grossen Kunden abhaengig machen. > Und? Geht es dir nur um einen Sprachenstreit? Ja, das Zeug ist teilweise "legacy", aber was soll's? Praktisch jede Firma verwendet Windows und hat kein Problem damit Windows-Software auszuführen. Ich halte Python fuer eine gute Wahl. Ich komme aus dem low level Umfeld und bin froh, dass ich dieses Know How habe. Ich bin keiner dieser Fanboys die aus dieser Python Sprache eine regelrechte Religion machen. Ich will plattformabhaengig entwickeln um selbst Kosten in der Produktion zu sparen. > Wenn Kunden Geräte wie Drehkreuze einsetzen, die im Extremfall Personen schwer verletzen oder töten können, dann haben sie gerne jemanden, der ihnen eine "Garantie" gibt, einen Versicherungsschutz... In meinem Fall sind das keine automatischen Drehkreuze. Es sind kleine Zugangsloesungen, die ueber einen potentialfreien Kontakt angesteuert werden. Faellt der Strom aus, sind diese dauerhaft offen. Neben der Softwareloesung gibt es noch eine mechanische. Ich bin uebrigens auch gelernter Elektroniker. > sondern gelangt in die Hand des Kunden? Ach, weil der Kunde für deine Anwendung jetzt noch einen Server betreiben muss? Du musst immer einen Server betreiben. Auser bei einer Einzelplatzinstallation. Da ist der Rechner Client und Server in einem. Er braucht keinen unabhaengigen Server, wenn die Software nicht Tag und Nacht laufen muss. Bei einem kleinen Buero mit 2 Arbeitsplaetzen reicht es, wenn einer davon auch der Server ist. > Wie viele der Kunden brauchen Plattformunabhängigkeit? Du sagst du kennst die Branche, also wie oft fragen Kunden danach? Wenn es um den Server geht fragen vor allem IT Dienstleister, ob sie das nicht mit einer Linux Maschine machen koennen. > Was meinst Du denn warum Linux bzw. Openoffice sich nicht durchgesetzt hat, obwohl es kostenlos ist? Weil es hierfuer fuer diese Art von Software keinen Markt gibt. Langsam gibt es aber einen. Weil die Kunden langsam die Gedult mit Microsoft verlieren (Lizenzen..., du zahlst inzwischen fuer jeden Benutzer in der Cloud. Bei einem Unternehmen mit wechselnden Personal einfach richtig umstaendlich). Zweitens wird die Hardwareansteuerung immer einfacher. Lesegeraete, Bondrucker, Drucker und andere Hardware kann komplett ueber Netzwerkschnittstellen angesteuert werden. > Einerseits kann Python natürlich Bytecode erzeugen. Das ist das normale Verhalten beim Laden von .py-Modulen, die dabei in .pyc-Dateien mit (ggf. optimiertem) Bytecode übersetzt werden. Das ist kein Bytecode. Du kannst den Quelltext immer noch lesen. Es gibt auch von Python selbst Programme die das rueckgaengig machen. Ich will meinen Quelltext nicht verunstalten. Ich moechte das erfahrene Leute erkennen, dass ich ordentlichen Code schreibe. Die Qualitaet des Quelltextes spiegelt sich im Programm. Die Java Uebersetzungen scheitern sicher wenn es um eingebundene Module geht. > Liegt an der Sprache: in einer Skriptsprache kann der Entwickler wesentlich schneller arbeiten als in kompilierten Sprachen... Sehe ich auch so. Ich brauche einige Module fuer die Software: Verschluesselung, Sockets, Grafik-Tools, Webserver Funktionen etc... Ich muesste bei C++ die Libraries immer wieder checken. Bei Python weiss ich, dass alles auf dem aktuellen Stand ist, wenn ich mit der derzeitigen Python Version Schritt halte. > Du hast keinen Business Case Das kann zu einem Problem werden. Ich komme von der technischen Seite. > So gesehen halte ich die Frage quelloffen oder nicht für einen Sturm im Wasserglas. Ich denke genauso. Muss ich ja, sonst wuerde ich das nicht probieren wollen. > Hatte ich leider schon, daß ein einzelner, guter Entwickler durch Flugzeugabsturz zu Tode kam. Seitdem mache ich um Einmann-Entwicklungen möglichst einen Bogen. Ich will nicht zwingend alleine bleiben. Wenn die Software funktioniert und ich mehr Leute brauche, dann stelle ich auch gerne Personen ein. Aber ich weiss auch, dass es bis dahin harte Arbeit sein kann. Vielleicht ist es auch nie moeglich. Die Software ist quelloffen, immerhin etwas falls ich von heute auf morgen nicht mehr da sein sollte. > Solch ein Geschäft kann man nur nebenbei anfangen um zu sehen wie es läuft... So wird es auch vermutlich geschehen. Vielen, vielen Dank fuer die vielen Antworten. Auch gut, dass hier und da mal wirklich aus dem "Naehkaestchen" berichtet wurde. Ich probiere das auf he
oszi40 schrieb: > FamilyGuy schrieb: >> Übrig geblieben ist die 1 Mann Klitsche. > > Ausnahmen bestätigen die Regel. > Was wird, wenn der EINE Mann in Rente ist? Stehen dann alle Drehkreuze > des o.g. Zurittssystems still, weil keiner ablaufende Zertifikate > erneuert? :-) Ich veräußere die Arbeit bevor ich in Rente gehe. Die meisten mittleren Unternehmen haben das Problem ja auch wenn der jeweilige Entwickler in Rente geht. Dann kommt der nächste und wird einfach in's Wasser geworfen.
FamilyGuy schrieb: > Ich veräußere die Arbeit bevor ich in Rente gehe. Die meisten mittleren > Unternehmen haben das Problem ja auch wenn der jeweilige Entwickler in > Rente geht. Dann kommt der nächste und wird einfach in's Wasser > geworfen. Ich bin nicht der ewige Pessimist. Aber es gibt z.B. einige Hotels, die seit Jahren einen Nachfolger suchen und nach sieben Jahren noch keinen geeigneten Käufer gefunden haben. Eine Firma gewinnbringend zu verkaufen, will gekonnt sein.
Egg schrieb: > Es gibt bisher keine Linux Loesung auf dem Markt. Das > sehe ich als Luecke und als Hoffnung. Die von mir zuvor beschriebene Lösung von CLS basierte auf SunOS 4 und sollte sich leicht auf Linux portieren lassen. Sie wurde damals(TM) von der Hannover Messe eingesetzt, musste aber - gegen den Willen der Messe - einer Lösung von Siemens weichen, weil auf der Expo 2000 nur politisch gut vernetzte Unternehmen präsentiert werden durften. Apropos Großunternehmen vs. Ein-Mann-Bude: Wie ich in einem anderen Thread erwähnt habe, hat Siemens vor einiger Zeit den Support für alte 8080-basierte Prozessrechner beendet, weil es sich nicht mehr um einen Wachtstumsmarkt handelt. Und damit haben etliche Kunden ein gewaltiges Problem. Die Größe eines Lieferanten besagt überhaupt nichts über die Liefertreue. Gerade Großunternehmen scheren sich da beliebig wenig um Bestandskundenwünsche.
Andreas S. schrieb: > Apropos Großunternehmen vs. Ein-Mann-Bude: > Wie ich in einem anderen Thread erwähnt habe, hat Siemens vor einiger > Zeit den Support für alte 8080-basierte Prozessrechner beendet, weil es > sich nicht mehr um einen Wachtstumsmarkt handelt. Und damit haben > etliche Kunden ein gewaltiges Problem. Die Größe eines Lieferanten > besagt überhaupt nichts über die Liefertreue. Gerade Großunternehmen > scheren sich da beliebig wenig um Bestandskundenwünsche. Aufgrund der Größe u. "Marktmacht" will man so die Kunden weitermelken - die sollen gefälligst migrieren, auch wenn das Bestandsmaterial noch locker zig Jahre könnte. Andererseits nutzen viele diese "Lücke" u. nehmen die Kunden an der Hand, Investitionsschutz ermöglicht den Aufbau eines eigenen Unternehmens. Da gibt es in der Geschichte von BigS schon einige Beispiele.
Wir verdienen mit offenem Quelltext auch unser Geld! Je nach Projekt nehmen wir aus dem offenen Quellcode die Teile die wir benötigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.