This topic contains 34 replies, has 14 voices, and was last updated by 
Jack 2 months ago.
-
Posts
-
Jhon M.
to put it very simple about open source, it’s all in the team management (and the team)
Open source doesn’t mean you have to accept just anything that comes from the community, you don’t even have to manage x versions of your software,
it’s all a choice.
In a case like AM, certainly, there would be code proposals, which need to be reviewed, tested and approved by CEL.About that quality, there are plenty of very high quality open source projects out there.
Linux being the prime example of course. There are gimp and blender for drawing, never heard the word inferior about it.
There is also a bunch of open source just for industries, ERP projects are the ones most visible for me.
And you have all the software packages that come in the same water as Mikey$oft …
They have a long history of sabotaging in a lot of sneaky ways other software suppliers and open source initiatives.
The one you name, Open Office, certainly is an example of such sabotage.@gid
I’m not attacking anything CEL has invented, I’m just making the observation nobody seems to work on their own version of “our” print head.
It is in the open for almost a year now (at least the idea), nobody else did anything with the idea.
And copying and stealing ideas, we got plenty of examples in the smartphones/tablet/… wars going on right now,
I’m pretty sure the 3D players on the market are no saints.java (EE), JavaFX, HTML, GIS) programmer, database wizard, framework inventor, looking for a job ! http://roboxing.com/wizards@pelgrim I don’t think you can draw any conclusions from whether or not competitors have copied the needle valve concept. There are other approaches to solving the problem of precise filament delivery and they may have chosen those instead. Or they haven’t got to it yet. Or that the Robox head’s patented in US, China and Europe, I believe. http://bit.ly/1FMjuNu
Regardless, I’m sure CEL believe they have unique proprietary software IP that’s worth keeping closed-source, and I’m guessing that’s most significantly contained in the Roboxiser. What I’m saying is that even if that bit is something they want to keep closed-source, there’s still potential benefits to open-sourcing or at least shared-sourcing the code (eg. allowing third party developers to assist under NDA).
However, I think doing so right now might overcomplicate and slow things down a lot. It drastically changes the dynamic of the development process, and I’m not sure it would be a productive change in the short term. In the vast majority of open-source projects, you rarely get any substantive contributions from outside developers, and when you do, they need a lot of code review and/or refactoring to get them to fit right. Since there’s at least one major unreleased branch of AM in development, changes made by outside developers could easily conflict with planned work, or repeat already completed but unreleased work.
Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locations.
- This reply was modified 2 months, 1 week ago by gid. Reason: (Damn forum duplicate posting again)
Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locationsLets again say - this is not against CEL by any means. On contrary. All we read here is just suggestions - what some people see might help current situation (and speed up future development).
Now Open Source is not same as Free Software. Java, AutoMaker is made on, for instance has most of its software open (not all!!!) and it is not Free software. It is allowed to be used for free in many ways, but there are still ways that are not completely Free. On the other hand there wouldn’t be AutoMaker to start with without Free and Open Source software: Slic3r (Free Software), Apache (commons, log4j, maven, …) - all under Apache License (pretty much Free), java simple serial connector (Lesser GNU - Free Software), controls-fx (Open Source - pretty much Free Software) and others… Without them CEL would need to put far more man hours in AutoMaker and it wouldn’t be as good as it is right now.
But, that’s not the point. Point is that there are people here who could/want to help and can speed up development and even help with new features of AutoMaker. And all that for free. Not because they love CEL - but because of it would benefit them as well and they might love what they are doing (coding)… Wouldn’t that benefit all? As I said in original post - I would rather spend 30minutes trying to figure out fix for a but for myself and then submit solution to CEL than raise ticked knowing that it might actually prevent some more important work (on improving hardware, logic in ‘roboxing’ as @gid said or work on dual material head). Especially CEL as serious company doesn’t want to be known for ‘good, but buggy software they have no time to address because of new features they develop’.
Similar goes to new features. Some of them may be simple gimmicks but will add value to AutoMaker and Robox for sheer existence, while others might prove to be really crucial and beneficial for large community. Would you just throw it away or postpone them for 6 months, year or more because them not being high on priority list? For instance - it is nice for all ‘projects’ to be ‘enumerated’ at the top of the window - but the moment that number goes over 10 - it seems quite messy and unorganised. Why not just having simple save/load as many applications have? So people can organise their projects nicely in sub-dirs, etc… That is not really a priority for CEL but could be very nice addition to already quite good app. And I bet at least 3 people here would agree to help/implement it…
Ah - I wrote another long post, I could go on forever - sorry for that O
A big company like Oracle can afford the lawyers necessary to protect the particular intellectual property that’s in Java. Open source projects like Slic3r and Apache don’t need that kind of protection, as they don’t have unique IP that they don’t want copying. If, however, someone took CEL’s idea of dual needle valves, ripped off that specific code inside, and brought a cheaper Robox clone to market without all the expense of R&D, as a small company CEL might not survive long enough to be victorious in lawsuits against those companies, even if it could afford the lawyers. Once established and thus with enough of a head start, that could change. On the other hand, when it comes to things like AutoMaker’s UI, which is nice but not particularly unique per se, they wouldn’t really be risking anything by open-sourcing it, and could benefit from doing so as you say.
Thing is, they’ve already said they’ve got hundreds of small fixes to do in their internal bug database that haven’t been tackled yet. Sure, we might be able to fix those, but managing those incoming patches / pull requests is a full-time job in itself; and even if they did that, there would be a substantial amount of new, foreign code in the codebase that the current developers don’t know… thus slowing them down for the big tasks as well: wrangling a complicated refactor into a codebase you wrote yourself and you’ve already got figured out in your head is hard enough. Doing it with the various contributions of a bunch of other programmers is another thing entirely.
Consider Brooks’s Law: “adding manpower to a late software project makes it later”. “Nine women can’t make a baby in one month.”
AutoMaker is currently being worked on intensely full time with large-scale changes being prepared on at least two separate branches. I guarantee that adding more developers at this point will slow that process down. If those are in-house developers, maybe it’s a time investment they can afford to make to benefit the longer term, but spending time dealing with outside volunteers with no declared commitment is a hefty investment for high risk.
In short, right now it’s probably quicker (and a lot simpler) for one of CEL’s developers to fix a small bug than it is for one of CEL’s developers to analyse, rewrite, integrate and regression test a patch for that same bug from an outside developer.
However…
Once AutoMaker’s done with this initial chunk of development and they’re concentrating more on new functionality and products with fewer time pressures, opening it up will become a lot more practical. As there will be more time to integrate their patches and far less time risk involved, outside contributors would at that point be beneficial. Whether or not CEL then decide to do that it up to them, and it looks like most of us would urge them to consider doing so.
Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locationsHi,
may someone from Robox team could say something to this topic?
too busy building the cathedral
no negativity intended, just can’t help myself lol.java (EE), JavaFX, HTML, GIS) programmer, database wizard, framework inventor, looking for a job ! http://roboxing.com/wizards
AnonymousConsider Brooks’s Law: “adding manpower to a late software project makes it later”. “Nine women can’t make a baby in one month.”
AutoMaker is currently being worked on intensely full time with large-scale changes being prepared on at least two separate branches. I guarantee that adding more developers at this point will slow that process down…
Isn’t that exactly what CEL are doing? They’re advertising for more developers and they’ve already added one guy. Those new guys will be unfamiliar with the code… we all know throwing more developers at a project never speeds it up.
This isn’t about speed though, it’s about individuals who are motivated to spend considerable time fixing bugs that are specific to their printing problem. Quite often a problem like that might just end up at the bottom of the pile for CEL… whereas if that one guy is allowed to make his fix, even if it isn’t introduced into the main code branch, then he still ends up as a happy user as he’s fixed his problem. This is the happy position that Ultimaker users are in…
Yes, that is what CEL’s doing… however if you read further in my post: “If those are in-house developers, maybe it’s a time investment they can afford to make to benefit the longer term”. Adding new developers at this time will slow the process down — unless it’s for very specific tasks within delineated code, eg. “write a new slicer”, but even that takes core developer time to write the spec, assess the code, and even skill-test interviewees. The difference is that adding a new developer employee is likely to result in a net productivity increase over time, whereas open-sourcing may not actually do that: there’s no guarantee that contributions from the community will ever outweigh the cost of supporting that process, and that’s not particularly uncommon in fact.
As I said, I agree that (in my opinion) it would be in CEL’s long-term interests to open-source it, or at least some parts of it if they’re touchy about the more proprietary/unique bits.
All I’m talking about here is the short-term consequences to open-sourcing it while AutoMaker is still in a constructive development phase (as opposed to a maintenance phase)
Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locationsYes, integrating / testing / QA’ing / UAT / etc. community changes at a time like this is a full time position (or more) and an administrative/management burden on a company that is already short staffed.
They are heads down at this point making corrections to the software which is where a lot of the issues are probably born (that and I have noticed some come in with issues not having performed any of the requisite calibrations at all).
-
This reply was modified 2 months ago by
Trekman42.
Argh - I can’t keep it in any more!
(I already had two long responses which I decide not to post - if nothing else but due to respect for CEL as a company - because I would like to support them and prevent anything to be seen as sheer criticism)Opening software shouldn’t necessarily should prevent/interfere with official development/release plans. If someone wants to build it outside of official releases - it would allow for it. At the same time would allow for two way features/code movement:
1. community (developers) to ‘fork’ code and try experimental features and more importantly provide fixes and
2. official development to take community fixes/features at the pace it suites the company
I do understand that such move takes time - especially if there’s need for half/half solution - half open/half close code parts.
But something slightly bothers me at the moment - and it is not really software being open or not at this point - it is lack of official/semi-official response from CEL. Nobody from CEL is posting in forums and all we get is second hand responses through @gid. And it doesn’t seem right. It is nice to ‘feel'(*) what CEL thinks (through him) but it is a bit detached and too… Also ‘feel’ at the moment is that CEL is not interested in nurturing community at this point - they have more important problems to take care of…
I really hope problems they are facing and solution they are working on are going to work out soon and that they’ll be free to face more outwards and engage more with us.
Hey, I don’t have any back-channel to CEL. I have visited them a few times to get my printer fixed and I get on well with them but other than the same kind of informal advice they’ve given to others and to the forums when they have time I’m not privy to any other info. I just read between the lines. I also know how this kind of small company operates, having been in the same position as the guys there many times before.
They are clearly extremely busy right now, and have been for a couple of months now. Chris W is apparently moonlighting as support since Pete W (the support manager) left, and they’re trying to recruit new support staff. No bloody wonder they’re not answering forum posts at the moment!
That conclusion not based on anything other than information they’ve put on the forums in the past couple of weeks, my own experience, and some logical reasoning.
As I’ve been in their position before, I can tell you that just opening software in any useful sense DOES take time, and unless even more time is invested to manage integration of changes back in, it would not benefit their timescales: in the short term at least, submitted code would be of insufficient quantity and probably quality (in terms of matching the bigger picture, that is… not disparaging anyone’s coding skills) to justify the time cost. Integrating someone else’s patch can often take more time than fixing the bug itself, and they don’t even have time to fix all the small bugs at the moment.
Oh, and that’s not even considering the whole new class of emails, posts and tickets they’ll start getting for “Developer Support”, ie. “Oh, if you can just help me learn Java, I can fix some bugs for you” (okay, I’m exaggerating there)
As I’ve said since the Kickstarter campaign succeeded they could do with communicating more. Anyone who’s managed development teams (and has also been a developer under pressure too) knows that one of the first things to go when time gets tight is communication. That, and/or documentation. As I said to a client today, I can either fix the problem or talk about fixing the problem.
That’s a possible explanation, not an excuse, btw… I do believe that with some more communication, they might calm people down a bit, and that might ease time pressures a bit. However, it’s their call.
Now we’re expecting them to write forum posts, answer tickets (with no support manager currently employed!), fix hardware, resolve bugs, rewrite AutoMaker, allow replacement of slicers (or evaluate and adapt new slicers), improve material handling, tune the profiles, recruit and train new staff, etc., etc. All of these are “Priority 1″ items. Fine. Now they’re also meant to open up their code, document it, and liaise with external volunteer developers (who might end up frying their heads because they sent the wrong GCode) too?
Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locations
You must be logged in to reply to this topic.